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 in 24 Stunden. 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.