„Wir brauchen eine App." Dieser Satz fällt in fast jedem Produkt-Meeting – und er kostet, wenn er unreflektiert umgesetzt wird, gerne zwischen 50.000 und 150.000 € für eine native iOS- und Android-Lösung, die dann noch sechs Wochen im App-Store-Review wartet. Dabei ist die Entscheidung Native App vs. PWA eine der teuersten im digitalen Produkt – falsch getroffen kostet sie nicht nur Geld, sondern Zeit, Momentum und manchmal auch Rankings.
Progressive Web Apps sind keine Notlösung für knappe Budgets. Sie sind eine technisch eigenständige Kategorie – und für viele Anwendungsfälle die bessere Wahl.
Was ist eine Progressive Web App?
Eine PWA ist eine Website, die sich durch drei technische Bausteine in eine App-ähnliche Erfahrung verwandelt:
Service Worker
Der Service Worker ist ein Script, das im Hintergrund läuft – unabhängig von der Webseite selbst. Er ermöglicht Offline-Fähigkeit (gecachte Inhalte werden angezeigt, wenn kein Netz vorhanden ist), Push-Notifications und Background-Sync. Ohne Service Worker keine echte PWA.
Web App Manifest
Das Manifest ist eine JSON-Datei, die dem Browser mitteilt: Wie soll die App heißen? Welches Icon soll auf dem Homescreen erscheinen? In welchem Modus soll sie öffnen (Vollbild, Standalone)? Ohne Manifest kann die App nicht installiert werden.
HTTPS
Kein verhandelbarer Punkt: Service Worker laufen nur über HTTPS. Das ist keine optionale Empfehlung, sondern technische Voraussetzung.
Was eine PWA wirklich kann
- Offline-Nutzung: Der Service Worker cached Ressourcen und Daten. Nutzer können auch ohne aktive Internetverbindung auf zuletzt geladene Inhalte zugreifen.
- Push-Notifications: Wie bei nativen Apps – allerdings mit Einschränkungen auf iOS (dazu gleich mehr).
- Installierbar: Nutzer können die PWA auf dem Homescreen installieren, ohne App Store. Der Browser zeigt einen „Zum Homescreen hinzufügen"-Prompt.
- Home-Screen-Icon und Splash Screen: Die App fühlt sich beim Start wie eine native App an – kein Browser-Chrome, kein URL-Feld, volles Bild.
Vorteile gegenüber nativen Apps
Das ist kein Marketing. Das sind konkrete strukturelle Vorteile:
Eine Codebase für alle Plattformen. Statt iOS und Android separat zu entwickeln, betreibt ihr eine Web-Codebase. Das bedeutet weniger Entwicklungsaufwand, weniger Bugs und eine einheitliche Update-Logik.
Kein App-Store-Review. Updates gehen sofort live – ohne Wartezeit, ohne Rejection-Risiko. Kritische Bug-Fixes sind in Minuten draußen, nicht in Tagen.
Updates sofort und automatisch. Nutzer müssen nicht aktiv updaten. Beim nächsten Besuch oder App-Start lädt der Service Worker im Hintergrund die neue Version.
SEO-fähig. Native Apps sind für Suchmaschinen unsichtbar. Eine PWA wird indexiert, rankt, bringt organischen Traffic. Das ist ein struktureller Vorteil gegenüber jeder nativen Lösung.
Deutlich günstiger. Eine hochwertige PWA kostet in der Entwicklung je nach Komplexität 20–60% weniger als eine vergleichbare native Lösung für iOS und Android. Laufende Wartung ist ebenfalls günstiger, weil es nur eine Codebasis gibt.
Einschränkungen – ehrlich eingeordnet
iOS ist (immer noch) ein Problem
Apple hat lange gebraucht, PWA-Features überhaupt zu unterstützen – und die Unterstützung ist bis heute eingeschränkter als auf Android. Push-Notifications auf iOS sind erst seit iOS 16.4 möglich, und nur wenn die PWA installiert ist. Viele Features funktionieren nur im Safari-Browser, nicht in Chrome oder Firefox auf iOS.
Wenn eure Zielgruppe stark iOS-lastig ist und Push-Notifications ein zentrales Feature ist, müsst ihr das einkalkulieren.
Kein vollständiger Hardware-Zugriff
Bluetooth und NFC sind in Browsern je nach Plattform stark eingeschränkt oder gar nicht zugänglich. Kamerasteuerung, Mikrofon und GPS funktionieren, aber komplexe Hardware-Integration (spezifische Sensor-APIs, tiefe System-Integration) ist weiterhin native Apps vorbehalten.
Keine App-Store-Sichtbarkeit
Was wie ein Vorteil klingt (kein Review), hat eine Kehrseite: Ihr verzichtet auf die Auffindbarkeit im App Store. Wer aktiv im App Store sucht, findet eure PWA nicht. Für Produkte, bei denen Discovery über App Stores ein echter Kanal ist, ist das relevant.
Für wen PWA sinnvoll ist
Die ehrliche Antwort: für mehr Anwendungsfälle als die meisten denken.
E-Commerce ist ein klassischer PWA-Use-Case. Produktkatalog, Warenkorb, Checkout – alles web-nativ, SEO-relevant, schnell. Starbucks, Alibaba und zahlreiche mittelständische Shops setzen auf PWA, weil die Conversion-Rates mit einer schnellen, installierbaren Webapp oft besser sind als erwartet.
News- und Content-Plattformen profitieren massiv von Offline-Fähigkeit und Push-Notifications. Der Nutzer liest auf dem Weg in die U-Bahn weiter – auch ohne Netz.
SaaS-Produkte mit klarer Desktop-und-Mobile-Nutzung sind prädestiniert. Eine PWA skaliert vom kleinen Handyscreen bis zum großen Monitor – ohne parallele Codebasis.
Buchungssysteme und Portale – Formulare, Terminverwaltung, Dashboards: Alles, was primär auf Interaktion und Datenverwaltung ausgelegt ist und keine tiefen Hardware-Features braucht.
Wann native App die bessere Entscheidung ist
Manche Anforderungen sprechen klar gegen eine PWA:
- Komplexe Hardware-Integration: NFC-Zahlungsterminals, Bluetooth-Gerätekopplung, tiefe OS-Integration, Background-Processes die immer aktiv sein müssen.
- Mobile Gaming: Echtes Gaming braucht nativen Performance-Zugriff. Die Browser-Engine ist hier strukturell limitiert.
- Stark native UX erwartet: Wenn die Zielgruppe eine Erfahrung erwartet, die sich wie die iOS-Einstellungen oder Android-native Patterns anfühlt – das lässt sich im Browser nicht vollständig replizieren.
- App-Store-Präsenz ist strategisch: Wer eine Marke über Apple App Store und Google Play aufbauen will, braucht native Einträge.
Kosten-Vergleich: PWA vs. native App
Eine grobe Orientierung, keine Garantie:
| | PWA | Native (iOS + Android) | |---|---|---| | Entwicklung | 15.000 – 60.000 € | 60.000 – 200.000 € | | Updates | Sofort, keine Store-Freigabe | Separat für iOS + Android | | Wartung p.a. | Eine Codebase | Zwei Codebases | | App-Store-Gebühren | Keine | Apple: 99 $/Jahr + 15–30% | | Time-to-Market | Schneller | Langsamer (Review 1–6 Wochen) |
Die tatsächlichen Zahlen hängen von Komplexität, Team und Scope ab – aber die strukturellen Unterschiede bleiben konstant.
Wie eine PWA technisch gebaut wird
Für Next.js-Projekte ist der Stack gut etabliert: next-pwa (oder der modernere Fork @ducanh2912/next-pwa) integriert sich in die next.config.ts und generiert automatisch Service-Worker-Logik auf Basis von Workbox – Googles Framework für Service-Worker-Caching-Strategien.
Das Web App Manifest wird als manifest.json im public-Ordner hinterlegt und im <head> verlinkt. Icons in verschiedenen Größen, ein theme_color, ein background_color, und ihr habt die Installierbarkeit aktiviert.
Workbox übernimmt die komplexe Cache-Logik: Was kommt aus dem Cache (Cache First)? Was wird immer frisch geladen (Network First)? Was passiert offline? Das lässt sich granular pro Asset-Typ steuern.
Bekannte PWAs in der Praxis
Wer noch zweifelt, ob PWA „echte Produkte" tragen kann: Twitter/X läuft auf Millionen Geräten als PWA – mit Offline-Fähigkeit, Push-Notifications und installiertem Icon auf dem Homescreen. Starbucks hat seine PWA-Order-App als Alternative zur nativen App gebaut und berichtet von ähnlicher Nutzungsrate wie die native iOS-App. Uber setzt für Märkte mit schwacher Internetverbindung auf eine PWA als Fallback.
Das sind keine Nischen-Use-Cases. Das sind skalierte Produkte mit Millionen Nutzern.
Die Entscheidung Native vs. PWA ist keine religiöse – sie ist eine architektonische. Wenn ihr dabei Begleitung wollt, schauen wir uns euren konkreten Anwendungsfall an und zeigen euch, welcher Weg für euer Produkt, euer Budget und eure Nutzerbasis der richtige ist.