Native App, Hybrid oder Web: entscheiden Sie, wie viel Plattform Sie tragen wollen

„Wir brauchen eine App.“ So beginnt fast jedes Gespräch, und in den meisten Fällen bedeutet der Satz etwas anderes: Wir müssen beim Nutzer griffbereit sein. Eine App im Store ist eine von mehreren Formen, griffbereit zu sein, und die teurere Form ist nicht automatisch die richtige. Ich arbeite seit über zehn Jahren an nativen iOS-Apps und habe mein eigenes Produkt trotzdem nicht als iOS-App gebaut.

Die Skala von der Web-App bis zur nativen App

Zwischen Browser und nativem Code liegt eine Skala. Sie sortiert sich danach, wie viel Plattform Sie selbst tragen: wer die Anwendung ausliefert, was zwischen iOS und Android geteilt wird und wie viel Code Ihr Team dauerhaft besitzt.

1. Web-App oder PWA. Ein Codestand, ausgeliefert durch den Browser, installierbar auf dem Homescreen. Kein Store, keine Freigabe, Updates sofort. Gerätezugriff nur so weit, wie der Browser ihn erlaubt.
2. Mini-App in einer Plattform. Dieselbe Web-Anwendung, nur läuft sie innerhalb von Telegram, WeChat oder einer vergleichbaren Umgebung. Die Plattform bringt die Nutzer mit, gibt dafür aber die Regeln vor.
3. WebView-Hülle. Capacitor oder Ionic verpacken den Web-Code in eine Store-App. Es gibt ein Icon im Store und native Brücken für einzelne Funktionen, der Rest bleibt Web.
4. UI vom Framework gezeichnet. React Native und Flutter teilen Oberfläche und Logik und rendern selbst. Zwischen Ihrem Code und dem Betriebssystem liegt eine Brücke, die jemand pflegen muss.
5. Geteilte Logik, native Oberfläche. Kotlin Multiplatform teilt Datenmodelle, Netzwerkschicht und Geschäftsregeln. Die Oberfläche wird auf jeder Plattform nativ gebaut, mit SwiftUI und mit Jetpack Compose.
6. Nativ. Zwei Codebasen, zwei Teams oder ein Team mit beiden Kompetenzen, voller Zugriff auf alles, was das Gerät kann.

Keine der Stufen ist besser als eine andere. Jede ist für eine bestimmte Antwort auf drei Fragen richtig.

Frage 1: Wo ist der Nutzer schon?

Eine App zu installieren ist eine Hürde. Store öffnen, suchen, laden, Konto anlegen, Berechtigungen bestätigen. Jede dieser Stufen kostet Nutzer, und bei Menschen, die Ihr Produkt nicht ohnehin suchen, kostet sie die meisten. Wenn die Zielgruppe bereits an einem Ort versammelt ist, lohnt die Frage, ob man nicht dorthin geht, statt sie herauszuholen.

Das war die Ausgangslage bei CognitEase, meinem eigenen Produkt: ein Praxis-Assistent für Psychologinnen und Therapeuten, der aus Sitzungsaufnahmen Dokumentation erstellt und Termine, Zahlungen und Videotelefonie abwickelt. Viele aus der Zielgruppe arbeiten ohnehin in Telegram. Eine eigene App hätte verlangt, dass sie eine weitere Plattform lernen.

Ich habe CognitEase deshalb als Web-Anwendung gebaut, ein Next.js-Frontend mit einem NestJS-Backend, und sie als Telegram Mini-App ausgeliefert. Keine Installation, kein Store-Prozess, die Nutzer sind schon da. Der Messenger ist dabei nur die erste Hülle. Dieselbe Anwendung läuft im Browser, und wenn eine Zielgruppe woanders sitzt, bekommt sie dort eine weitere Hülle, ohne dass das Produkt neu gebaut wird. Diese Beweglichkeit ist der eigentliche Vorteil der Web-Stufe, und sie war für mich als iOS-Entwickler das stärkere Argument.

Der Preis dieser Entscheidung ist der Rahmen, den die jeweilige Hülle setzt. Innerhalb von Telegram bestimmt Telegram, was eine Mini-App darf, wie sie geöffnet wird und wie sie aussieht. Benachrichtigungen laufen über den Bot statt über System-Push, und eine sichere Ablage auf dem Gerät wie der native Schlüsselbund fehlt. In den App Stores ist CognitEase nicht zu finden. Diese Kosten waren bekannt und sind kleiner als die Hürde, die eine Installation für diese Zielgruppe bedeutet hätte.

Frage 2: Wie tief müssen Sie ins Gerät?

Die zweite Frage schiebt die Entscheidung in die andere Richtung. Es gibt Anforderungen, die sich nur mit nativem Code erfüllen lassen oder nur dort verlässlich: NFC, biometrische Freigabe, Schlüsselmaterial im Secure Enclave, zertifikatsgebundene Verbindungen, Hintergrundprozesse, die das System nicht beliebig beenden darf. Jede davon zieht die Grenze auf der Skala nach unten.

In einem Projekt im stark regulierten Gesundheitsumfeld ging es um Authentifizierung und Security: OpenID Connect, FIDO, mutual TLS, Zertifikats-Pinning, Schlüssel im Keychain, dazu das Auslesen einer Gesundheitskarte per NFC. Keine dieser Anforderungen lässt sich an einen Browser oder an eine Framework-Brücke delegieren, ohne dass die Sicherheitsargumentation Lücken bekommt. Diese Schicht blieb nativ.

Nativ galt aber nur für diese Schicht. Oberhalb der Sicherheitsschicht lag Logik, die auf iOS und Android identisch sein musste. Das Auslesen der Karte lief über ein Kotlin-Multiplatform-Modul, das beide Plattformen teilten; Datenmodelle und Netzwerkschicht ebenso. Die Oberfläche blieb auf iOS in SwiftUI, die Interop zum bestehenden Swift-Code war Teil der Arbeit. Das ist Stufe fünf der Skala, bewusst gewählt, weil Stufe sechs für diese Logik doppelte Arbeit ohne Gewinn gewesen wäre.

Der Preis hier sind zwei Werkzeugketten in einem Projekt. Kotlin-Build, Swift-Build, Testing in beiden Welten, eine Interop-Grenze, die Disziplin verlangt. Für ein Team, das beide Plattformen ohnehin bedient, ist das tragbar. Für ein Team mit einer einzelnen iOS-Entwicklerin wäre es keine Erleichterung, sondern eine zweite Baustelle.

Frage 3: Wie viel Plattformcode wollen Sie besitzen?

Die dritte Frage betrifft das Team nach dem Launch. Code, der Ihnen gehört, muss jemand verstehen, aktualisieren und bei jedem neuen iOS- und Android-Release prüfen. Die Skala ist deshalb auch eine Skala der Betriebskosten.

Am oberen Ende besitzen Sie Web-Code und sonst nichts. Am unteren Ende besitzen Sie zwei vollständige Plattform-Codebasen. Dazwischen liegt die Frage, wer die Brücke pflegt. Bei React Native und Flutter ist die Brücke das Framework selbst; es löst das Problem der doppelten Oberfläche, verlangt aber, dass jemand im Team die Brücke versteht, wenn ein natives Modul fehlt oder ein Betriebssystem-Update das Rendering verändert. Mit React Native und Flutter habe ich nicht in Produktion gearbeitet. Ich kenne die Mechanik der Brücke, nicht ihre Betriebskosten aus erster Hand, und bewerte diese Stufe deshalb von außen.

Praktisch heißt die Frage: Wie viele Plattformen kann Ihr Team in zwei Jahren noch ernsthaft bedienen? Eine, zwei oder keine? Die Antwort ordnet die Wahl oft deutlicher als jede Feature-Liste.

Die falsche Abkürzung

Der häufigste Fehler, den ich sehe, ist die Wahl nach dem, was das vorhandene Team gerade kann. Ein Web-Team baut eine WebView-Hülle, obwohl die Anforderungen ins Gerät reichen. Ein iOS-Team baut nativ, obwohl die Nutzer in einem Messenger sitzen und keine Installation wollen. Beides funktioniert anfangs und wird zwei Jahre später neu gebaut, dann mit Nutzern, Daten und Terminen im Rücken.

Die drei Fragen lassen sich beantworten, bevor eine Zeile Code existiert, und von außen prüfen. Wer eine Stufe empfiehlt, sollte sagen können, welche Antwort auf welche Frage ihn dorthin geführt hat.

Grenze

Die Skala hilft bei der Wahl, nicht bei der Umsetzung. Zwei Dinge löst sie nicht.

Sie sagt nichts über Qualität innerhalb einer Stufe. Eine schlecht gebaute native App verliert gegen eine gut gebaute PWA, und umgekehrt. Und sie gilt für Produkte, deren Anforderungen man kennt. Bei einem frühen Produkt, das seinen Markt erst sucht, ist die Antwort auf alle drei Fragen vorläufig. Dann wählt man die Stufe, die den Wechsel am wenigsten bestraft, und das ist in der Regel die mit dem wenigsten eigenen Plattformcode.

Schluss

Die Frage „nativ oder hybrid“ lässt die Stufen aus, auf denen die Antwort oft liegt: im Browser, in einer Plattform, in der die Nutzer schon sind, oder in geteilter Logik unter nativer Oberfläche. Wo ist der Nutzer schon, wie tief müssen Sie ins Gerät, wie viel Code wollen Sie besitzen. Diese drei Fragen stelle ich im Erstgespräch vor jeder Diskussion über Frameworks.