React Native 2026: Wann Native, PWA oder Expo für eine SaaS Mobile App?
Die Frage React Native vs PWA beginnt fast nie als Engineering-Frage. Sie beginnt als Wachstumsannahme: "Unsere Wettbewerber haben eine App, also brauchen wir auch eine." Bis sie beim Gründungsteam ankommt, ist sie zu einem Roadmap-Punkt geronnen, und niemand hat innegehalten und gefragt, ob die Präsenz im App Store für das Geschäft tatsächlich etwas ändert. Für die meisten B2B-SaaS-Produkte lautet die ehrliche Antwort: nein. Und der Preis dafür, das auf die teure Art herauszufinden, ist eine native Codebasis, die zwei deiner fünf Engineers ab jetzt dauerhaft pflegen.
Dieser Post ist ein Entscheidungsframework, kein Technologieüberblick. Das Ziel ist, dir bei der Entscheidung zu helfen, ob du überhaupt Native brauchst, und falls ja, ob Expo oder ein Bare-React-Native-Workflow zu deinem Team passt. Wir auditieren Codebasen beruflich, und die Mobile-Entscheidung ist einer der häufigsten Punkte, an denen sich ein kleines Team still zu einer Wartungslast verpflichtet, die nie eingeplant war.
React Native vs PWA richtig framen: Starte mit fünf Fragen, nicht mit einer Technologiewahl
Native ist gerechtfertigt, wenn dein Produkt eine Plattformfähigkeit braucht, die der Browser nicht erreicht, oder wenn App-Store-Distribution eine geschäftliche Anforderung ist und keine Präferenz. Alles andere ist ein Web-Problem im App-Kostüm. Bevor irgendjemand eine Zeile React Native schreibt, beantworte diese fünf Fragen ehrlich.
Erfordert die Kernerfahrung Push-Benachrichtigungen, die zuverlässig ankommen, wenn die App geschlossen ist? Web Push existiert, und auf Android ist es solide. Aber wenn Push zentral für deinen Produkt-Loop ist, liefert Native nach wie vor die verlässlichste Zustellung und die reichhaltigste Notification-Oberfläche.
Braucht sie tiefen Hardware-Zugriff, etwa die Kamera als vollwertigen Input, biometrische Authentifizierung mit Anbindung an die Secure Enclave, Bluetooth oder NFC? Ein Dokumentenscanner, ein Tool für Vor-Ort-Inspektionen oder ein Begleiter für ein Zahlungsterminal haben einen echten Native-Case. Ein Dashboard nicht.
Braucht sie Offline-First-Daten mit Konfliktauflösung, bei denen Nutzer stundenlang ohne Verbindung Datensätze anlegen und bearbeiten und später synchronisieren? Das ist im Web mit IndexedDB und Service Workern baubar, aber die Ergonomie einer nativen lokalen Datenbank und von Background Sync ist spürbar besser, sobald das Datenmodell komplex wird.
Braucht sie echte Hintergrundverarbeitung: Standort-Tracking, große Uploads, die nach dem Backgrounding der App weiterlaufen, oder geplante lokale Arbeit? Der Browser begrenzt das bewusst. Native nicht.
Ist die App-Store-Präsenz eine geschäftliche Anforderung, weil deine Käufer im Store suchen, deine Enterprise-Kunden MDM-Distribution verlangen oder dein Pricing auf In-App-Käufen basiert? Manchmal ist der Store selbst das Feature. Das ist ein legitimer Grund, aber benenne ihn als Distributionsentscheidung, nicht als technische.
Wenn du alle fünf mit Nein beantwortet hast, hast du kein Native-Problem. Du hast eine Web-App, die installierbar sein sollte, und du kannst aufhören, Stellenanzeigen für React-Native-Entwickler zu lesen.
Die PWA-Grenze 2026, ehrlich benannt
Das stärkste Argument gegen Native für die meisten SaaS-Produkte ist, dass eine Progressive Web App inzwischen die unspektakuläre Mitte des Marktes abdeckt. Eine PWA installiert sich auf den Homescreen, läuft im Vollbild ohne Browser-Chrome, funktioniert offline über einen Service Worker und shippt sofort ohne Review-Warteschlange. Für ein Datenerfassungstool, eine interne Admin-Oberfläche oder einen Dashboard-Begleiter zu einem Desktop-Produkt ist das häufig die gesamte Anforderung.
Was sich geändert hat: iOS hat bei den Punkten aufgeholt, die früher Dealbreaker waren. Seit dem iOS-16- und iOS-17-Zyklus unterstützen installierte Web-Apps auf dem iPhone Web Push, Badging und ein wirklich brauchbares installiertes Erlebnis. Damit ist die Lücke geschlossen, die Android-only-PWAs jahrelang schwer verkäuflich machte. Auf Android ist die Lage schon lange gut. 2026 ist eine PWA also eine ernsthafte Antwort, kein Fallback.
Die Grenze ist trotzdem real, und du solltest genau wissen, wo sie liegt, bevor du dich festlegst. Auf iOS funktioniert Web Push nur für installierte Apps und bleibt für zeitkritische Zustellung weniger zuverlässig als Native. Hintergrundausführung ist eng gedeckelt: Kontinuierliches Standort-Tracking oder garantierten Background Sync wie in einer nativen App bekommst du nicht. Tiefe Hardware-Integration wie Bluetooth und NFC ist in Safari inkonsistent oder nicht verfügbar. Und du bist nicht im App Store, was genau dann zählt, wenn deine Käufer dort tatsächlich suchen.
Lies diese Liste gegen deine fünf Antworten. Wenn keine dieser Grenzen dein Produkt berührt, ist eine PWA plus eine gut gebaute responsive Web-App kein Kompromiss. Sie ist die richtige Architektur, und sie ist die, die wir in einem Tech-Stack-Strategie-Engagement am häufigsten empfehlen, weil sie eine komplette Plattform von der Wartungsfläche entfernt.
Wo Expo passt, und warum Bare React Native selten der richtige Start ist
Angenommen, du hast die Fragen durchgearbeitet und Native ist gerechtfertigt. Die nächste Weggabelung ist Expo versus ein Bare-React-Native-Projekt, und hier unterschätzen Teams die operativen Kosten des Bare-Pfads.
Expos Managed Workflow lässt ein Team eine echte React-Native-App shippen, ohne eine native Build-Umgebung zu besitzen. Du schreibst JavaScript und TypeScript, Expo Application Services baut die Binaries in der Cloud, Over-the-Air-Updates lassen dich JavaScript-Änderungen ohne neues Store-Review pushen, und das Config-Plugin-System deckt die meisten Native-Module-Bedürfnisse ohne Ejecting ab. Für ein Fünf-Personen-Unternehmen ohne dedizierten Mobile-Engineer ist das nahezu Pflicht. Die Alternative ist die Pflege von Xcode- und Android-Studio-Toolchains, Provisioning Profiles, Signing-Zertifikaten und nativen Dependency-Graphen, ein Teilzeitjob, für den in einem kleinen Team niemand Kapazität übrig hat.
Der alte Einwand gegen Expo, dass du gegen eine Wand läufst, sobald du ein nicht unterstütztes Native-Modul brauchst, ist weitgehend obsolet. Das Config-Plugin-Ökosystem und Development Builds bedeuten, dass du eigenen nativen Code hinzufügen und trotzdem die Managed-Build- und Update-Pipeline behalten kannst. Bare React Native ergibt Sinn, wenn du wirklich ungewöhnliche native Anforderungen hast oder eine bestehende native App erweiterst. Für eine Greenfield-SaaS-Mobile-App ist es meist der falsche Default. Starte managed und ejecte erst, wenn eine konkrete Anforderung es erzwingt.
Die Illusion vom geteilten Code mit deiner Next.js-Web-App
Das verführerischste Argument für React Native ist Code-Sharing: "Wir haben schon eine Next.js-App, also bedeutet React Native ein Team, eine Sprache, geteilte Logik." Ein Teil davon stimmt, ein Teil ist eine Falle, und der Unterschied entscheidet, ob die geteilte Codebasis Geld spart oder es still kostet.
Was wirklich geteilt wird, ist die nicht-visuelle Schicht. TypeScript-Typen, Validierungsschemata, API-Client-Code, Formatierungs- und Geschäftslogik sowie Domain-Modelle wandern sauber zwischen Web und Native. Pack das in ein geteiltes Package, und beide Apps konsumieren es. Das ist echter Hebel und es lohnt sich, dafür zu strukturieren.
Was nicht geteilt wird, ist der Komponentenbaum. React Native rendert kein HTML und nutzt kein CSS; es hat eigene Primitives und ein eigenes Layoutsystem. Dass eine React-Web-Komponente und eine React-Native-Komponente denselben Namen tragen, heißt nicht, dass sie eine Implementierung teilen. Teams, die erwarten, ihre Web-UI in der App wiederzuverwenden, stellen fest, dass Navigation, Gesten, Listen, Formulare und Plattformkonventionen alle auseinanderlaufen, und die "geteilte Komponente" wird zu zwei Implementierungen hinter einem Interface. React Native for Web kann einen Teil davon überbrücken, aber es als Weg zu behandeln, deine bestehende Site in einer App laufen zu lassen, produziert meist etwas, das sich auf beiden Plattformen falsch anfühlt.
Das richtige mentale Modell: Teile die Logik aggressiv, teile die Komponenten fast nie, und budgetiere die App-UI als komplett neue Arbeit. Wenn du das Projekt in dem Glauben scopest, die UI sei größtenteils Wiederverwendung, liegst du um ungefähr die gesamten Kosten der App daneben. Das ist ein häufiger Befund, wenn wir ein Code-Quality-Review an einem festgefahrenen Cross-Platform-Projekt durchführen.
Die Wartungskosten, die niemand in die Schätzung schreibt
Die Build-Schätzung ist die kleine Zahl. Die Wartungskosten sind die, die ein Fünf-Personen-Unternehmen überraschen, und es lohnt sich, sie explizit zu modellieren, bevor du dich festlegst.
Das App-Store-Review fügt jedem Release Latenz hinzu. Ein dringender Fix, der in Minuten in deine Web-App shippt, wartet für die Mobile-Version in einer Review-Warteschlange. Also übernimmst du entweder Over-the-Air-Updates für JavaScript-Änderungen oder akzeptierst, dass Mobile und Web auf unterschiedlichen Release-Kadenzen laufen. Native Dependency-Upgrades kommen im Takt der Plattformen, nicht in deinem: Jedes Jahr shippen iOS und Android Änderungen, die Builds brechen können, und du musst Schritt halten oder fällst aus den unterstützten Toolchains. Bei Expo ist die SDK-Migrationskadenz echte laufende Arbeit, denn aktuell zu bleiben ist Voraussetzung, um die Managed Pipeline und die neueste React-Native-Version zu behalten. Und jede native Library, die du hinzufügst, ist eine Abhängigkeit, die aufgegeben werden, an der nächsten OS-Version brechen oder ein Upgrade blockieren kann.
Nichts davon ist ein Grund, Native zu vermeiden. Es ist ein Grund, sicherzustellen, dass der Wert da ist, bevor du dich verpflichtest, und ehrlich dafür zu staffen. Eine native App ist kein einmaliger Build; sie ist ein zweites Produkt mit eigenem Release-Zug, und ein Team, das sie als Feature scopet, spürt den Widerstand innerhalb von zwei Release-Zyklen. Diese Realität in den Plan einzubauen ist genau die Art von Thema, die ein Partner für individuelle Softwareentwicklung vor dem ersten Sprint in die Diskussion zwingen sollte.
Eine Entscheidungszusammenfassung, mit der du arbeiten kannst
Arbeite die Fragen der Reihe nach ab. Wenn keine Plattformfähigkeit und keine Distributionsanforderung Native rechtfertigt, baue eine exzellente responsive Web-App und mach sie zu einer installierbaren PWA. Das deckt mehr B2B-SaaS-Produkte ab, als die meisten Gründer erwarten, und hält dein ganzes Team auf einer Codebasis.
Wenn Native wirklich gerechtfertigt ist, starte mit Expos Managed Workflow statt mit Bare React Native, teile deine TypeScript-Logik zwischen Web und Mobile, plane die App-UI aber als neue Arbeit, und nimm den laufenden Wartungszug, Review-Verzögerungen, Dependency-Upgrades und SDK-Migrationen vom ersten Tag an ins Budget. Wähle Native, weil eine Anforderung es verlangt, nicht weil ein Wettbewerber ein Icon auf einem Homescreen hat.
Wenn du vor dieser Entscheidung stehst und eine zweite Meinung willst, die auf deinem tatsächlichen Produkt und deiner Teamgröße basiert statt auf einer generischen Best Practice, ist das genau die Art von Gespräch, bei der wir helfen. Erreiche uns unter hello@wolf-tech.io oder auf wolf-tech.io, und wir sagen dir ehrlich, ob du überhaupt eine App brauchst.