Nativ, React Native oder Web-App: wie man wirklich entscheidet

Hier die kurze Antwort. Entscheiden Sie nach Distribution und Hardware-Bedarf, nicht nach Mode. Kommt Ihr Nutzer über einen Link oder QR-Code und soll nichts installieren, bauen Sie fürs Web. Brauchen Sie eine echte Präsenz in beiden App-Stores mit einem Team und einer Codebasis, bauen Sie mit React Native. Hängt das Produkt von tiefem Hardware-Zugriff, einer Uhr oder Gesundheitsintegrationen ab, bauen Sie nativ. Der Rest dieses Leitfadens ist die Begründung hinter diesen drei Sätzen.

Die Frage, die entscheidet

Die meisten Technologie-Debatten über Apps beginnen am falschen Ort: bei der Technologie. Der nützliche Ausgangspunkt sind zwei Fragen zu Ihrem Produkt. Erstens: Wie kommt Ihr Nutzer an? Über einen geteilten Link, über einen Code auf dem Tisch, über die Suche in einem App-Store oder über etwas, das bereits auf dem Startbildschirm installiert ist? Zweitens: Was braucht die App tatsächlich vom Gerät? Einen Bildschirm und eine Internetverbindung, oder Kamera, Offline-Speicher, Push-Benachrichtigungen, Standort im Hintergrund, eine gekoppelte Uhr?

Beantworten Sie diese beiden Fragen ehrlich, und die Plattformwahl ergibt sich fast von selbst. Der Rest ist Budget und Zeitplan, und beide folgen ebenfalls aus denselben zwei Antworten.

Web und PWAs: der unterschätzte Standard

Kommt der Nutzer über Link oder QR-Code, ist jeder Installationsschritt eine Mauer zwischen ihm und Ihrem Produkt. Niemand, der an einem Restauranttisch steht, lädt eine App herunter, um die Speisekarte zu lesen. Deshalb ist Smart Menu, Cazullos Produkt für digitale Speisekarten, eine Web-App: Der Gast scannt den Code und die Karte ist einfach da, in seiner Sprache, mit Fotos, in Sekunden. Ein App-Store würde Reibung hinzufügen und Nutzer abziehen.

Das moderne Web reicht auch weiter, als viele Einkäufer annehmen. Eine Progressive Web App, eine PWA, lässt sich auf dem Startbildschirm anheften, funktioniert offline und synchronisiert, sobald die Verbindung zurückkehrt. Ein Außendienstteam kann seinen ganzen Tag mit einer Offline-First-PWA bestreiten, ohne dass jemand einen App-Store anfasst, und das Unternehmen liefert Updates sofort aus, ohne Prüfschleife und ohne darauf zu warten, dass Nutzer aktualisieren. Für Produkte, die in einem Browser-Moment leben, ist das Web nicht die billige Option. Es ist die richtige.

React Native: ein Team, zwei Stores

Manchmal ist die Store-Präsenz das Produkt. Eine Community-Commerce-App, die Menschen namentlich suchen, auf dem Startbildschirm behalten und jede Woche öffnen, verdient ihren Platz als installierte App. Das klassische Problem sind die Kosten: Dasselbe Produkt zweimal zu bauen, einmal in Swift für iOS und einmal in Kotlin für Android, bedeutet zwei Teams, zwei Codebasen und jede Funktion doppelt bezahlt.

React Native löst genau das. Eine Codebasis, geschrieben von einem Team, kompiliert zu echten Apps für beide Stores. So funktioniert die Cazullo Platform: Die White-Label-Apps für lokalen Handel sind mit React Native und Expo gebaut, und eine einzige Codebasis veröffentlicht viele Marken-Apps, jede unter eigenem Namen, im App Store und bei Google Play. Erscheint eine Funktion, bekommt sie die App jeder Marke. Diese Ökonomie ist mit zwei nativen Codebasen unmöglich und für Produkte, die die Hardware nicht ausreizen, unnötig.

Nativ: wann es seine Kosten verdient

Vollständig native Entwicklung, Swift auf Apple-Plattformen oder Kotlin auf Android, ist der teuerste Weg, und manchmal ist er jeden Euro wert. Das Signal ist die Tiefe der Integration. Braucht das Produkt eine Apple-Watch-App, liest und schreibt es Gesundheitsdaten über HealthKit oder stützt es sich auf Plattformfunktionen, sobald sie angekündigt werden, wird eine Cross-Platform-Schicht zur Reibung statt zum Hebel.

Cazullo baut in nativem Swift, wenn das Produkt zuerst für das Apple-Ökosystem gedacht ist: wenn die Uhr, die Gesundheitsdaten und die enge Integration mit dem Gerät das Produkt sind, kein Extra. In dieser Situation ist Nativ kein Statussymbol. Es ist das einzige Werkzeug, das das erreicht, was Sie verkaufen.

Die falschen Gründe

• Nativ aus Status wählen: "Ein richtiges Unternehmen hat eine native App" ist Marken-Logik, angewendet auf eine Ingenieursentscheidung, und kann das Budget verdoppeln, ohne sichtbaren Nutzen für den Nutzer
• Web nur wegen der Kosten wählen, wenn die Auffindbarkeit im App-Store DER Marketingplan ist: Wenn Nutzer den Store namentlich durchsuchen, ist Sparen durch Abwesenheit kein Sparen
• Ein gut funktionierendes Web-Produkt ohne jeden Gerätebedarf als installierte App neu bauen: Eine App, die eine Website hätte bleiben können, fügt Installationshürden, Prüfzyklen und Update-Verzögerung hinzu, für nichts

Checkliste

• Wie kommt der Nutzer an: über Link und QR-Code oder über die Suche in einem App-Store?
• Würde ein verpflichtender Installationsschritt den Nutzer genau in dem Moment verlieren, in dem er Sie wollte?
• Braucht das Produkt Hardware, die der Browser nicht erreicht: Uhr, Gesundheitsdaten, Sensoren im Hintergrund?
• Müssen Sie vom ersten Tag an in beiden Stores präsent und auffindbar sein?
• Wie viele Codebasen können Ihr Team und Ihr Budget ehrlich über Jahre pflegen?
• Wie oft werden Sie Updates ausliefern, und können Sie die Prüfzeiten der Stores tolerieren?
• Muss die App offline funktionieren, und wie tief?
• Könnte eine PWA die Offline- und Startbildschirm-Anforderungen ganz ohne Store abdecken?

Unsere abschließende Empfehlung ist einfach. Beginnen Sie mit dem Web und bleiben Sie dort, solange es Ihrem Nutzer dient. Wechseln Sie zu React Native, wenn Store-Präsenz und die Beziehung einer installierten App wirklich zählen, und lassen Sie eine Codebasis beide Plattformen tragen. Reservieren Sie Nativ für Produkte, bei denen das Gerät selbst der Punkt ist. Die beste Plattform ist nicht die beeindruckendste. Es ist die, über die Ihr Nutzer nie nachdenken muss.