Native App vs. Cross-Plattform vs. PWA: wann was passt

„Sollen wir nativ entwickeln oder cross-plattform?” ist die zweithäufigste Frage in unserem Posteingang. Die ehrliche Antwort: es kommt auf sechs Treiber an, und keiner davon ist „was ist gerade hip”. Hier ist die Heuristik, mit der wir selbst entscheiden, und die du in zehn Minuten durchgehen kannst, bevor du dich auf einen Pfad festlegst.

Was die drei Optionen wirklich sind

• Native (Swift für iOS, Kotlin für Android). Du schreibst zwei Codebasen mit den jeweiligen Plattform-Sprachen und -Toolchains. Maximaler Zugriff auf Plattform-APIs, beste Performance an den Spitzen, doppelter Entwicklungsaufwand und doppelte Wartungslast.
• Cross-Plattform (React Native + Expo). Eine Codebasis in TypeScript, native Kompilierung in zwei Apps. Praktisch alle wichtigen APIs sind über Expo-Modules und das React-Native-Ökosystem verfügbar. Performance liegt für die typischen App-Use-Cases nahe an Native, mit eindeutigen Spitzen-Szenarien (Echtzeit-3D, intensive native Threads), in denen sich die Differenz spürbar zeigt.
• PWA (Progressive Web App). Eine Web-App, die im Browser läuft, sich aber „App-artig” verhält: Home-Screen-Icon, Offline-Cache, Push (eingeschränkt). Kein Store, keine Submission, sofortige Updates ohne Review. Dafür kein voller Zugriff auf Plattform-APIs und keine Store-Sichtbarkeit.

Cross-Plattform meint hier explizit React Native + Expo. Flutter, Capacitor und Co. landen in derselben Schublade, lösen aber andere Trade-offs aus, die hier nicht das Thema sind.

Sechs Entscheidungs-Treiber

1. Performance-Spitze

Wenn die App in der Hot Path mehr macht als CRUD-Screens (Echtzeit-Audio, intensive 3D-Visualisierungen, kontinuierliche Sensor-Pipelines, Video-Bearbeitung), fällt PWA sofort raus. Native und React Native sind realistisch; native ist messbar schneller, aber für die meisten App-Klassen reicht React Native ohne spürbaren Unterschied. Native lohnt sich, wenn ein konkreter Performance-Engpass nachweislich nicht in RN lösbar ist, sonst trägt die Cross-Plattform-Variante zwei Plattformen mit halber Wartungslast.

2. Hardware- und Sensor-Zugriff

Bluetooth-LE-Pairing zu spezifischer Hardware, NFC, ARKit/ARCore, schwere Kamera-Pipelines, BLE-Mesh-Steuerung. Hier wird der Unterschied groß. React Native deckt den breiten Bedarf über Expo-Modules und etablierte Community-Libraries ab; bei tiefen Hardware-Integrationen prüfst du zuerst, ob ein Modul existiert. Wenn nein und die Funktion ist Kern-Feature: Native erwägen, gegebenenfalls als isoliertes Native-Modul innerhalb der RN-App. PWA fällt für nicht-triviale Hardware-Tiefe komplett aus.

3. Offline-Anspruch

PWAs können Offline (Service Worker, IndexedDB), aber das Offline-Verhalten in iOS-Safari ist über die Jahre unzuverlässig geworden, Cache-Lebensdauer ist kurz, Hintergrund-Sync limitiert. Wenn deine User regelmäßig offline arbeiten müssen (Außendienst, Lager, Industrie-Hallen), ist eine echte App stabiler. Offline als Kern-Feature → React Native oder Native. Offline als „nice to have für Tunnelfahrten” → PWA reicht meist.

4. Store-Sichtbarkeit als Akquise-Kanal

Wenn deine User die App über Suche im Store finden sollen, brauchst du eine Store-Präsenz. PWAs erscheinen nicht im Store. Beide Stores akzeptieren weder reine „Web-Wrapper” noch Apps, die im Wesentlichen nur eine Webview öffnen. Apple zieht das ausdrücklich in den App Review Guidelines (4.2 Minimum Functionality) durch. Wer den Store als Discovery-Kanal nutzen will, fährt mit React Native oder Native. App als reiner Service-Layer für bestehende Kunden, die per Mail/Onboarding eingeladen werden → PWA kann reichen.

5. Update-Geschwindigkeit

PWAs aktualisieren sich automatisch beim nächsten Aufruf. React Native erlaubt mit Expo Updates / EAS Update Over-the-Air-Updates für JS-Bundle-Änderungen. Bugfixes und kleine Feature-Tweaks landen ohne Store-Review beim User. Native hat keinen vergleichbaren OTA-Pfad: jede Änderung geht durch den Store-Review. Wenn schnelle Iterations-Schleifen Teil des Produkt-Modells sind, ist React Native der Sweet Spot, App-Erlebnis plus Web-artige Update-Geschwindigkeit für den Großteil der Änderungen.

6. Team-Skill und Wartungslast

Native zwingt zu zwei Teams oder zu einem Team mit zwei Toolchains. React Native lässt eine Codebasis in TypeScript laufen. Viele Web-Teams können in den Stack hineinwachsen. PWA ist meist ein bestehendes Web-Team mit kleinem Manifest-/Service-Worker-Aufschlag. Das Team, das das System langfristig wartet, sollte den Stack ohne Reibung führen. Native rechnet sich nur, wenn entweder dauerhaft zwei Mobile-Spezialist:innen vorhanden sind oder eine externe Wartung das übernimmt, siehe AppCare vs. Stundenbasis vs. interner Entwickler.

Drei Praxis-Pfade

B2C-Mass-Market-App, Store als Akquise-Kanal, schnelle Iteration. Sovion-Default ist React Native + Expo, Stripe + RevenueCat für Monetarisierung, OTA-Updates über EAS. Native nur, wenn ein einzelner Hot-Path-Use-Case (z. B. AR oder Live-Audio) nicht in RN lösbar ist, und dann gegebenenfalls als isoliertes Native-Modul innerhalb der RN-App.

B2B-Tool für definierten Nutzerkreis (eigene Kund:innen, Außendienst, Mitarbeiter:innen). Wenn der Nutzerkreis dich aktiv installiert: PWA prüfen, bevor App. Spart Store-Submission und beschleunigt Iteration. Wenn Offline, Push oder Hardware-Tiefe relevant: React Native + Expo. Native nur bei spezifischen Hardware-Anforderungen.

Internes Werkzeug oder Companion-App zu einem Hardware-Produkt. Companion-Apps zu IoT/Werkzeug-Hardware verlangen oft tiefen BLE/NFC-Zugriff und werden in Branchen mit langen Sales-Zyklen über Jahre gewartet, siehe Industrie & IoT. React Native + Expo trägt das Setup; isolierte Native-Module für die Hardware-Brücke, falls nötig.

Wenn Web und Mobile am selben Backend hängen

Häufig ist die eigentliche Frage nicht „Native oder Cross-Plattform”, sondern wie viel Web und Mobile sich teilen sollen. Zwei wiederkehrende Architekturen, die wir bei Sovion als Multi-Plattform-Setups führen:

• Geteilter Stack: Eine API, zwei Frontends mit demselben Funktionsumfang. Cross-Plattform passt hier fast immer. Eine Codebase fürs Mobile, eine fürs Web, ein Backend für beide. Der Nutzer wählt pro Situation, ob Browser am Schreibtisch oder App unterwegs.

• Geteiltes System: Zwei bewusst unterschiedliche Oberflächen für unterschiedliche Rollen, z. B. eine schlanke Endkunden-App und ein Verwaltungs-Portal im Browser. Cross-Plattform fürs Mobile, Web-Stack fürs Portal, geteiltes Backend, getrennte UI-Codebases. Wartung bleibt überschaubar, weil die Trennung sauber ist und beide Frontends gegen denselben Vertrag arbeiten.

Beide Setups sind kein Sonderfall. Sie sind eher die Regel, sobald ein Produkt eine zweite Zielgruppe oder einen Backoffice-Teil bekommt. Praktisch heißt das: Monorepo mit gemeinsamen Types und Schemas, ein Repository-Set, eine Release-History, eine Übergabe.

Was du nicht nach Hype entscheiden solltest

Das Argument „Flutter ist gerade angesagt” oder „Native ist immer besser” ist in beide Richtungen Mode-Argument. Was zählt:

• Wie lange willst du die App betreiben? Je länger, desto wichtiger ist die Wartungslast, die in einer Codebasis (RN) signifikant niedriger ist als in zwei (Native).
• Wer wartet die App in 24 Monaten? Wenn die Antwort „weiß ich noch nicht” ist, gewinnt die Option mit der breitesten Hire-Basis. Das ist React Native + TypeScript, mit Abstand.
• Wo liegt der wirkliche Engpass? Meist in Backend, Onboarding-Flow, Datenmodell, nicht in der UI-Schicht. Die Plattform-Wahl ist seltener entscheidend, als die Diskussion suggeriert.

Wenn du unsicher bist, beschreib uns die App in drei Sätzen: Nutzergruppe, primärer Use-Case, vorhandene Hardware-/Offline-Anforderungen. Wir sagen ehrlich, welcher Pfad trägt, und ob in deinem Fall ein PWA-Pilot vor dem App-Build der schnellere Validierungsweg ist. Schick die Eckdaten über das Kontaktformular, Antwort zeitnah. Mehr Kontext zur Stack-Logik davor: Custom-Dev vs. No-Code/Low-Code, wann die Frage „native oder cross” überhaupt erst losgeht. Praxis-Beispiele auf Leistungen → Entwicklung und in den Branchen-Detailseiten.