„Wir brauchen eine App." Der Satz ist fast immer eine Abkürzung für etwas anderes: Wir wollen auf dem Homescreen sein. Wir wollen Push-Nachrichten schicken. Wir wollen, dass es sich wie ein Produkt anfühlt, nicht wie eine Website.
Keines dieser drei Ziele setzt einen App Store voraus. Das ist der Kern der Entscheidung — und der Grund, warum wir bei den meisten Projekten mit einer Progressive Web App anfangen und erst später, wenn überhaupt, nativ werden.
Was eine PWA 2026 kann
Eine Progressive Web App ist eine Website, die sich installieren lässt und die Fähigkeiten mitbringt, die früher nativen Apps vorbehalten waren. Der Stand auf iOS und Android:
- Installation auf dem Homescreen mit eigenem Icon, ohne Browser-Rahmen — auf beiden Plattformen
- Push-Benachrichtigungen — auf Android seit Jahren, auf iOS seit Version 16.4 für installierte PWAs
- Offline-Betrieb über einen Service Worker, der Inhalte und Anfragen zwischenspeichert
- Kamera, Standort, Dateizugriff, Teilen-Dialog über Web-APIs
- Ein Build für alles — dieselbe Codebasis läuft im Browser, installiert und auf dem Desktop
Was eine PWA nicht kann: tief in das Betriebssystem eingreifen. Bluetooth-Peripherie, Hintergrundverarbeitung über längere Zeit, App-Store-Abrechnung, Widgets, ein Eintrag im App Store selbst. Auf iOS ist einiges davon eingeschränkt oder nur in Safari verfügbar.
Was React Native bringt — und was es kostet
React Native erzeugt echte native Apps für iOS und Android aus einer gemeinsamen Codebasis. Damit ist der volle Zugriff auf das Betriebssystem da, die App steht im Store, und Nutzer erleben sie wie jede andere App.
Der Preis dafür ist Betrieb. Zwei Store-Prozesse mit Review-Zyklen. Jedes Update braucht eine Freigabe, und Nutzer installieren es nicht alle sofort — es gibt immer mehrere Versionen in freier Wildbahn. Native Module müssen bei jedem Betriebssystem-Update geprüft werden. Wer Web-Komponenten wiederverwenden will, kann das nur teilweise.
Realistisch liegen Aufbau und laufender Betrieb einer React-Native-App beim Zwei- bis Dreifachen einer PWA mit demselben Funktionsumfang.
Die Entscheidung in drei Fragen
Braucht das Produkt etwas, das nur nativ geht? Bluetooth, Hintergrund-Tracking, In-App-Käufe über den Store, AR-Funktionen. Wenn ja, ist die Entscheidung gefallen. Wenn die Antwort „nicht wirklich" lautet, weiter.
Ist der Store selbst ein Kanal? Manche Produkte werden über die Store-Suche gefunden. Für die meisten B2B- und Dienstleistungsangebote ist das nicht der Fall — der Weg führt über die Website, den Vertrieb oder den QR-Code am Standort, und dort funktioniert die PWA direkt ohne Umweg über einen Download.
Wissen wir schon, ob das Produkt funktioniert? Wenn nein, ist der teuerste Fehler, es nativ zu bauen und dann festzustellen, dass die Nutzer etwas anderes wollen. Eine PWA lässt sich in Tagen ändern, nicht in Review-Zyklen.
Warum Nuxt für die PWA
Nuxt bringt das mit, was eine PWA braucht, ohne dass man es zusammensetzen muss: serverseitiges Rendering, damit die öffentlichen Seiten des Produkts auch für Suchmaschinen sichtbar sind, ein Modul für Service Worker und Manifest, ein Routing, das im Browser und installiert gleich funktioniert.
Das ist der Punkt, der oft übersehen wird: Eine PWA ist gleichzeitig Produkt und Marketing-Website. Die Landingpage, der Login und die Anwendung selbst leben in einem System. Bei einer nativen App braucht es zusätzlich eine Website — und damit zwei Dinge, die gepflegt werden müssen.
Wir liefern das Ganze über Cloudflare aus, an der Edge, mit den Zeiten, die Google aus echten Nutzerdaten misst. Wie wir das technisch aufsetzen, steht auf der Seite zu Development.
Ein typischer Verlauf
So sieht es bei uns in den meisten Fällen aus:
Phase 1 — PWA. Kernfunktion, Login, Push, Homescreen-Installation. Live in Wochen. Echte Nutzer, echte Daten, echtes Feedback.
Phase 2 — Verdichten. Was wird genutzt, was nicht. Welche Anfragen kommen. Wo hakt es. Das Produkt wird schärfer, ohne dass ein Store-Review dazwischenliegt.
Phase 3 — Nativ, wenn es einen Grund gibt. Wenn nach Phase 2 klar ist, dass eine native Fähigkeit oder der Store-Kanal echten Wert bringt, wird die App nativ gebaut — mit dem Wissen aus Phase 2 statt mit Annahmen. Oft bleibt es bei der PWA.
Was das für Kosten bedeutet
Eine PWA mit Login, Push und Offline-Fähigkeit liegt im Aufbau meist im mittleren fünfstelligen Bereich, abhängig vom Funktionsumfang. Eine vergleichbare React-Native-App startet darüber und bringt laufende Kosten für zwei Plattformen mit. Die konkreten Zahlen hängen am Produkt — was wir dazu sagen können, steht in Was kostet eine Website?.
Wann wir direkt nativ empfehlen
Es gibt sie, die Fälle: Ein Produkt, das Hardware anspricht. Eine App, deren Geschäftsmodell auf In-App-Käufen beruht. Ein Consumer-Produkt, bei dem der Store-Auftritt Teil der Marke ist. Dann ist React Native die richtige Wahl, und wir sagen das im Erstgespräch.
Für alle anderen ist die ehrliche Empfehlung: Fangt mit der PWA an. Sie ist schneller am Markt, günstiger im Betrieb, und sie lässt euch die native Entscheidung treffen, wenn ihr wisst, wofür.
Wenn ihr gerade vor dieser Frage steht, schreibt uns, was die App können muss. Ihr bekommt eine Einschätzung, die auch „PWA reicht" lauten darf.
