Progressive Web Apps sind 2026 keine experimentelle Technologie mehr, sondern ein produktionsreifer Ausgabe-Kanal, der für einen großen Teil der typischen Mittelstands-Anwendungsfälle die kostengünstigste und schnellste Lösung darstellt. Gleichzeitig hat sich die Lücke zu nativen Apps in genau definierten Bereichen — Gesundheits-Sensoren, Augmented Reality, tiefe System-Integration — kaum geschlossen. Wer pauschal „wir machen eine App“ entscheidet, ohne die heutigen PWA-Capabilities zu kennen, verbrennt regelmäßig sechsstellige Budgets für einen marginalen Mehrwert. Wer umgekehrt pauschal auf PWA setzt, ohne die iOS-Eigenheiten und App-Store-Pflichten zu kennen, landet nach drei Monaten in einer Sackgasse. Dieser Artikel ordnet die Realität ein: was PWA heute tatsächlich kann, wo die Grenzen liegen, wie der Hybrid-Weg mit Capacitor funktioniert, und welche Empfehlung wir für welchen Anwendungsfall geben. Für die übergeordnete Einordnung siehe unseren Softwareentwicklungs-Guide sowie den Schwesterartikel Native vs Hybrid Mobile.
PWA-Realität 2026 — der Capabilities-Stand
Drei Entwicklungen haben das PWA-Bild zwischen 2022 und 2026 grundlegend verändert. Erstens hat Google mit dem sogenannten Capabilities Project — auch unter dem Codenamen Project Fugu bekannt — über 80 Web-APIs in Chromium produktionsreif gemacht, von Datei-System-Zugriff über Web-Bluetooth bis zu Web-Serial und Web-USB. Diese APIs sind in Chrome, Edge und allen Chromium-basierten Browsern stabil verfügbar. Zweitens hat Apple mit iOS 16.4 im März 2023 endlich Web-Push für Safari geliefert und in den folgenden Releases — iOS 17, 18, 26 — weitere Capabilities ergänzt, darunter Badging, verbessertes Storage-Management und Web-Share. Drittens haben sich die Tooling-Frameworks — Workbox, Vite-PWA, Next-PWA — so weit professionalisiert, dass Service-Worker-Setup heute eine Aufgabe von Stunden, nicht Wochen ist.
Die wichtigste strategische Botschaft daraus: die Browser-Engines auf Android sind 2026 mit nativen Apps in fast allen Bereichen außer kontinuierlichem Background-Tracking und tiefer Sensorik gleichauf. Auf iOS bleibt Safari der Engpass, aber selbst dort sind die kritischen Kern-Features — Push, Offline, Home-Bildschirm-Installation, Kamera-Zugriff, Geolocation, Touch-ID-äquivalente Authentifizierung über WebAuthn — produktionsreif. Wer also pauschal sagt „PWAs funktionieren auf iOS nicht“, argumentiert auf einem Wissens-Stand von 2022.
Wichtig für die Mittelstands-Realität: die meisten B2B-Apps, Mitarbeiter-Tools und Self-Service-Portale brauchen genau die Capabilities, die heute überall verfügbar sind — Authentifizierung, Offline-Lesezugriff, einfache Datei-Auswahl, Push für Statusbenachrichtigungen, Kamera für Belege. Für diese Klasse von Anwendungen ist PWA 2026 der Standard-Weg, nicht die Ausnahme.
Was eine PWA heute kann
Die folgenden Funktionen sind produktionsreif und in allen großen Browsern — Chrome, Edge, Firefox, Safari — verfügbar oder hinreichend gut unterstützt:
- Service-Worker und Offline-ModusLokales Caching von App-Shell, Assets und API-Antworten über die Cache-API und IndexedDB. Auch komplexe Offline-Szenarien mit lokalem Schreiben und Background-Sync funktionieren zuverlässig auf Android und iOS, mit der Einschränkung, dass Safari Storage nach sieben Tagen Inaktivität löscht.
- Push-Notifications auch auf iOS 16.4 und neuerEchte Push-Zustellung über APNS auf installierten PWAs am iPhone, inklusive Aktions-Buttons und Badging. Auf Android über FCM ohnehin seit Jahren stabil. Push ist damit kein PWA-Nachteil mehr, sondern ein Capabilities-Feature, das gleichberechtigt zu nativen Apps ist.
- Background-Sync und Periodic-Background-SyncVerzögerte Synchronisation, wenn das Gerät wieder online ist — etwa für Formulare, die offline ausgefüllt wurden. Periodic Sync für regelmäßiges Hintergrund-Aktualisieren funktioniert auf Chromium, auf Safari nur eingeschränkt.
- Web-Share und Web-Share-TargetEchte Integration in das native Teilen-Menü von Android und iOS — sowohl Senden aus der PWA in andere Apps als auch Empfangen geteilter Inhalte aus anderen Apps in die PWA. Praktisch wichtig für alles, was mit Dokumenten oder Fotos arbeitet.
- Web-Bluetooth, Web-USB, Web-SerialDirekter Zugriff auf Bluetooth-Low-Energy-Geräte, USB-Hardware und serielle Schnittstellen aus dem Browser — auf Chromium produktionsreif, auf Safari nicht verfügbar. Für Industrie-Anwendungen, Wartungs-Tools und IoT-Konfiguratoren sehr relevant.
- File-System-Access-APILesen und Schreiben echter Dateien auf dem Gerät, inklusive Schreibrechten in vom Nutzer ausgewählten Verzeichnissen. Auf Chromium produktionsreif, auf Safari nur Lesezugriff über das klassische File-Input-Element.
- WebAuthn und PasskeysBiometrische Authentifizierung über Face-ID, Touch-ID, Windows-Hello und Android-Biometrie direkt aus dem Browser. Funktioniert überall — auf iOS, Android, Windows, macOS — und ersetzt für die meisten Login-Szenarien das Passwort vollständig.
Diese Liste zeigt, dass die populäre Vorstellung „PWAs sind eingeschränkte Web-Apps“ nicht mehr stimmt. Für die typischen Anwendungsfälle des Mittelstands deckt der Web-Stack mittlerweile dieselben Capabilities ab wie native Apps — mit einer einzigen Codebasis, einem einzigen Deployment, ohne Store-Review-Zyklen.
Was eine PWA nicht kann
Trotz aller Fortschritte gibt es klar abgrenzbare Bereiche, in denen PWA technisch nicht reicht. Ehrlichkeit an dieser Stelle erspart später teure Refactorings.
| Bereich | Status PWA 2026 | Konsequenz |
|---|---|---|
| HealthKit, Apple Health, Google Fit Schreibzugriff | Nicht verfügbar | Health-Apps brauchen native iOS- und Android-Module |
| ARKit, ARCore für Augmented Reality | Nur einfache WebXR-Szenen | AR-Produkt-Anproben und Indoor-Navigation brauchen nativ |
| Vollzugriff auf Kontakte und Anruf-Historie | Nicht verfügbar | CRM-Telefonie und Voice-Apps brauchen nativ oder Capacitor-Wrapper |
| Kontinuierliches Background-Tracking | Nicht verfügbar auf iOS, eingeschränkt auf Android | Lauf-Apps, Geofencing-Marketing brauchen native Komponenten |
| Tiefe Sensor-Integration (Gyroskop, Beschleunigung, Magnetometer in hoher Frequenz) | Eingeschränkt verfügbar, oft mit Permission-Friktion | Spiele, AR und Vermessungs-Tools brauchen nativ |
| App-Clips und Instant-Experiences | Nicht verfügbar | Marketing-Mini-Apps mit App-Clip-Codes brauchen iOS-nativ |
| Apple-Pay und Google-Pay als In-App-Käufe | Web-Payments funktionieren, aber nicht für digitale Güter im App-Store-Kontext | Abo-Modelle für digitale Inhalte über Stores brauchen native In-App-Purchases |
Diese Einschränkungen sind nicht „temporär“ — sie sind plattform-politisch begründet, vor allem auf iOS. Apple hat kein wirtschaftliches Interesse, sein App-Store-Geschäftsmodell durch eine vollständig auf Augenhöhe stehende Web-Plattform zu erodieren. Wer also Sensoren, AR oder kontinuierliches Tracking braucht, muss diese Komponenten nativ bauen — entweder als reine native App oder, häufiger, als Hybrid-App mit Capacitor- oder React-Native-Wrapper.
Kostenlose PWA-Strategie-Beratung anfordern
Sie stehen vor der Entscheidung PWA, nativ oder Hybrid? Wir bewerten Ihren Anwendungsfall in einem 30-minütigen Erstgespräch — kostenfrei, ohne Verpflichtung. Sie bekommen eine klare Empfehlung mit Architektur-Skizze und realistischem Kostenrahmen.
Kostenlose Strategie-Beratung anfordernApp-Store-Listing-Pflichten 2026
Die Frage „können wir mit einer PWA in den Store?“ wird häufig gestellt und hat 2026 eine differenzierte Antwort, die sich auf beiden Plattformen unterscheidet.
Auf Google Play ist der Weg über Trusted Web Activities — TWA — seit Jahren produktionsreif. Eine TWA ist im Kern ein Mini-Wrapper, der eine PWA in einem vollwertigen Chrome-Tab ohne Adressleiste startet. Aus Nutzersicht ist das nicht von einer nativen App zu unterscheiden — eigenes Icon, eigener Splash, eigenes Task-Switcher-Bild, Push, Offline, alles. Aus Code-Sicht ist die TWA eine zehn-Zeilen-Konfiguration, die der Bubblewrap-CLI oder PWABuilder generiert. Updates der App passieren automatisch über den Web-Deployment, nicht über das Play-Store-Review. Das ist ein erheblicher operativer Vorteil.
Auf dem Apple App Store ist die Situation strenger. Apple hat die Review-Richtlinien zwischen 2023 und 2025 mehrfach verschärft, mit dem Tenor, dass reine WebView-Wrapper ohne nativen Mehrwert nicht akzeptiert werden — die berüchtigte Richtlinie 4.2. Ein einfacher PWA-Wrapper über WKWebView wird heute regelmäßig abgelehnt. Akzeptiert werden Apps, die substanzielle native Funktionen ergänzen — etwa Apple-Pay-Integration, eigene Widgets, ShareKit-Integration, Health-Kit-Synchronisation, native Push-Konfiguration. Genau hier setzt der Capacitor-Weg an, der in einem späteren Abschnitt detailliert wird.
Pragmatisch heißt das: wer auf Play-Store-Präsenz angewiesen ist, kommt mit einer reinen PWA plus TWA-Wrapper aus. Wer App-Store-Präsenz braucht, sollte von Anfang an einen Capacitor- oder React-Native-Wrapper einplanen, der die nativen Mindest-Anforderungen erfüllt. Wer Stores ganz weglassen kann und auf Web-Distribution setzt, spart sich beide Wrapper-Schichten — was zugleich der Discoverability-Frage zuführt.
Discoverability ohne App-Store
Eine PWA ohne Store-Listing wird über das Web gefunden, nicht über App-Store-Optimization. Das hat strategische Konsequenzen. Für B2B-Tools, Mitarbeiter-Apps, Self-Service-Portale ist Web-Distribution oft sogar besser, weil Sie SEO-Sichtbarkeit, Google-Ads, LinkedIn-Targeting und QR-Code-Onboarding-Flows nutzen, die im Store-Kontext nicht funktionieren. Eine PWA hat eine echte URL, ist verlinkbar, im Web-Archiv erfassbar und wird von Suchmaschinen indexiert. Ein App-Store-Eintrag ist hier paradoxerweise ein Sichtbarkeits-Nachteil.
Für consumer-orientierte Apps mit Massen-Reichweite ist umgekehrt die App-Store-Präsenz oft unverzichtbar — schlicht, weil Nutzer dort suchen. Hier hilft TWA für Play und der Capacitor-Weg für Apple, ohne dass Sie zwei separate Codebases pflegen müssen.
Performance-Vergleich Real-World
Im messbaren Performance-Vergleich zwischen einer gut gebauten PWA und einer mittelmäßig gebauten nativen App liegt die PWA häufig vorn — was viele Entscheider überrascht. Der Grund ist banal: native Apps werden in Stores ausgeliefert, sind oft groß, laden viel Code beim Start und bekommen Updates seltener. Eine PWA lädt nur den aktuellen App-Shell, ist meist unter 500 Kilobyte initial, startet auf modernen Geräten unter einer Sekunde und holt sich Updates instant aus dem Service-Worker.
Wo native unbestritten gewinnt: Echtzeit-Grafik, Spiele, intensive Animation mit komplexen Layer-Compositions, sehr hochfrequente Sensor-Verarbeitung. Für Business-Apps, Formulare, Dashboards, Bestelllisten und CRM-Frontends ist die Performance-Differenz dagegen 2026 nicht mehr wahrnehmbar — vorausgesetzt, die PWA ist sauber gebaut mit Code-Splitting, Pre-Caching und einem modernen Framework wie Next.js, SvelteKit oder Nuxt. Für die Stack-Empfehlung siehe WebApp-Stack 2026.
Push-Notifications iOS 16.4+ in der Praxis
Die wichtigste Funktion, die viele zu lange als PWA-Schwachpunkt geführt haben, ist seit drei Jahren produktiv: Web-Push auf iOS. Es gibt aber drei Realitäts-Punkte, die in Architektur-Entscheidungen einfließen sollten.
Erstens funktioniert Web-Push auf iOS nur, wenn der Nutzer die PWA über das Teilen-Menü auf den Home-Bildschirm legt — eine klassische Web-Seite kann keinen Push senden. Diese Installations-Hürde reduziert die adressierbare Push-Basis im Vergleich zu Android, wo das Browser-eigene Install-Prompt automatisch eingeblendet wird. Praktisch bedeutet das einen Onboarding-Flow mit explizitem „Zum Home-Bildschirm hinzufügen“-Banner und einer kurzen Erklärung.
Zweitens gibt es bei iOS-Web-Push keine Silent-Push-Variante, wie sie native Apps für stille Hintergrund-Updates nutzen. Jeder Push erscheint visuell. Für Use-Cases, die auf stille Hintergrund-Synchronisation angewiesen sind — etwa Fleet-Tracking — ist das relevant, für klassische Status-Updates, Erinnerungen, Bestätigungen nicht.
Drittens ist die Quote der erlaubten Push-Opt-ins auf iOS PWAs typischerweise niedriger als bei Android — die zusätzliche Installations-Hürde filtert. Empirisch liegen die Opt-in-Quoten auf installierten PWAs aber bei rund 40 bis 60 Prozent der Vergleichswerte einer nativen iOS-App — und damit deutlich besser als der häufig zu lesende Pessimismus.
Installation-UX — Add-to-Homescreen
Die Installations-UX ist auf den beiden Plattformen unterschiedlich gelöst. Auf Android öffnet Chrome bei manifest-konformen PWAs automatisch ein Install-Banner, sobald Engagement-Kriterien erfüllt sind — der Nutzer kann mit einem Tap installieren. Auf iOS muss der Nutzer aktiv über das Teilen-Symbol „Zum Home-Bildschirm“ wählen — kein automatischer Prompt, kein Banner.
Diese Asymmetrie ist ein UX-Thema, kein technisches. Erfolgreich umgesetzte PWAs ergänzen für iOS-Safari einen eigenen kontextuellen Install-Hinweis nach dem zweiten oder dritten Besuch — mit kurzer Animation, die das Teilen-Symbol zeigt und den „Zum Home-Bildschirm“-Eintrag hervorhebt. Konvertierungs-Raten von rund 15 bis 25 Prozent sind dabei realistisch — niedriger als auf Android, aber ausreichend für einen aktiven Push-Kanal.
Hybrid-Approach mit Capacitor
Für Anwendungen, die im Apple App Store präsent sein müssen oder einzelne native Capabilities brauchen, ist der Capacitor-Wrapper-Weg die wirtschaftlich überlegene Lösung. Capacitor — entwickelt vom Ionic-Team — verpackt eine bestehende Web-Codebasis in eine native Hülle, ergänzt eine kleine, klar abgegrenzte Schicht nativer Module für die fehlenden Capabilities und liefert die App in beide Stores aus.
In der Praxis sieht das so aus: Sie bauen Ihre Anwendung primär als PWA, mit allen Web-Vorteilen — schnelle Deployments, ein Codebasis, Web-Distribution. Für die Store-Auslieferung packt Capacitor diese Web-App in eine native iOS- und Android-Schale ein. Wo nativer Code nötig ist — Health-Kit, ARKit, In-App-Purchases — schreiben Sie kleine Plugin-Module, die der Web-Code per JavaScript-Bridge aufruft. Der Aufwand für diese Plugins ist oft nur wenige Personentage, die Investition lohnt sich, wenn die Store-Präsenz strategisch wichtig ist.
Der wirtschaftliche Vorteil: gegenüber zwei vollständig nativen Apps spart der Capacitor-Weg typischerweise 50 bis 70 Prozent der Entwicklungs- und Wartungskosten, bei einem Funktions-Umfang, der für 90 Prozent der Mittelstands-Anwendungsfälle ausreicht. Detaillierter zu nativ-vs-hybrid siehe unseren Cluster zu Native vs Hybrid Mobile.
Kosten-Vorteil PWA
Die Kosten-Asymmetrie ist der eigentliche Treiber der PWA-Entscheidung. Die folgende Tabelle zeigt typische Spannen für eine mittelgroße Anwendung — rund 30 bis 50 Bildschirme mit Authentifizierung, Datenhaltung, Push und Offline-Modus.
| Ausgabe-Variante | Erst-Entwicklung | Jahres-Wartung | Time-to-Market |
|---|---|---|---|
| Reine PWA, Web-Distribution | 60.000 – 110.000 € | 12.000 – 24.000 € | 3 – 5 Monate |
| PWA + TWA für Google Play | 65.000 – 120.000 € | 14.000 – 26.000 € | 3 – 5 Monate |
| PWA + Capacitor für beide Stores | 85.000 – 160.000 € | 20.000 – 36.000 € | 4 – 6 Monate |
| Zwei native Apps (iOS Swift + Android Kotlin) | 180.000 – 320.000 € | 40.000 – 80.000 € | 6 – 10 Monate |
Über drei Jahre Betrieb gerechnet ergibt sich für die meisten Anwendungsfälle ein Kosten-Vorteil der PWA-basierten Varianten zwischen 50 und 65 Prozent gegenüber dual-nativer Entwicklung — bei gleichzeitig schnellerer Time-to-Market und kontinuierlichen Deployments ohne Store-Review-Zyklen. Für die generelle Kostenstruktur siehe Softwareentwicklung Kosten 2026.
Reepa-Empfehlung pro Anwendungsfall
Die Wahl zwischen PWA, Capacitor-Hybrid und nativ lässt sich für die meisten Mittelstands-Szenarien klar machen. Die folgende Zuordnung fasst unsere Beratungs-Praxis zusammen.
- B2B-Portale, Self-Service, KundenportaleReine PWA, Web-Distribution. Keine Stores, kein Wrapper. SEO-Sichtbarkeit, einfache Updates, niedrigste Kosten. Beispiel: unser eigenes Kundenportal.
- Interne Mitarbeiter-Tools, Außendienst-AppsPWA mit optional TWA für Play Store, wenn das Onboarding über einen Store-Link einfacher ist. Sonst direkte Installation über QR-Code und Add-to-Homescreen.
- Buchungs- und Bestell-Apps für EndkundenPWA plus Capacitor für beide Stores, wenn Store-Präsenz strategisch ist. Sonst PWA plus TWA reicht für die meisten Marken.
- Content-orientierte Apps, Magazine, NewsletterReine PWA. Push für neue Inhalte, Offline-Lesemodus, Web-Share-Integration — alles über Web-Standards.
- E-Commerce-FrontendsPWA als Standard, Capacitor-Wrapper nur, wenn Push und Apple-Pay-Integration über Store-Channel benötigt werden. Web-Payments funktionieren über die PWA direkt.
- Health-Tracking, Fitness, WellnessNative oder Capacitor mit substanziellen nativen Plugins für HealthKit und Google Fit. Reine PWA reicht nicht.
- AR-basierte Apps, Indoor-Navigation, SpieleNative, in Ausnahmen Capacitor mit ARKit-Plugin. PWA scheidet aus.
- IoT-Konfiguratoren, Industrie-Wartungs-ToolsPWA mit Web-Bluetooth und Web-Serial — auf Android und Windows ideal. Auf iOS Capacitor-Wrapper mit Bluetooth-Plugin nötig.
Häufige Fragen
Reicht heute eine PWA für ein mittelständisches Mobile-Projekt aus?
Für rund 70 Prozent der typischen Mittelstands-Anwendungsfälle reicht eine PWA. Das gilt insbesondere für Mitarbeiter-Tools, B2B-Portale, Self-Service-Anwendungen, Buchungs- und Bestellsysteme sowie content-orientierte Apps. Sobald tiefere Hardware-Integration wie HealthKit, ARKit, Bluetooth-LE-Profile außerhalb der Web-Bluetooth-Whitelist oder kontinuierliches Background-Tracking benötigt wird, kommen Sie an einer nativen oder hybriden Lösung nicht vorbei.
Funktionieren Push-Benachrichtigungen auf iPhones inzwischen wirklich?
Ja, seit iOS 16.4 vom März 2023 unterstützt Safari Web-Push-Notifications für PWAs, die der Nutzer ausdrücklich auf den Home-Bildschirm hinzugefügt hat. Die Push-Zustellung läuft über das Apple Push Notification Service, ist zuverlässig und unterstützt Aktions-Buttons. Die wichtigste Einschränkung ist die Installations-Hürde — der Nutzer muss aktiv über das Teilen-Menü installieren, eine automatische Install-Prompt wie unter Android gibt es nicht. Die Opt-in-Rate liegt typischerweise zwischen 40 und 60 Prozent der nativen App-Pushes.
Kann eine PWA in den App Store und Play Store?
Im Google Play Store ja — über die Trusted-Web-Activity-Technologie wird eine PWA als regulärer Play-Store-Eintrag publiziert, mit identischer Codebasis und automatischer Aktualisierung. Im Apple App Store ist es deutlich strenger: ein reiner WebView-Wrapper wird seit den 2023er Richtlinien-Updates abgelehnt, akzeptiert werden nur Apps mit substanziellem nativen Wert. Wer in beiden Stores präsent sein will, geht typischerweise den Capacitor- oder React-Native-Wrapper-Weg, der für iOS native Module ergänzt.
Wie groß ist der Kostenvorteil einer PWA gegenüber zwei nativen Apps?
Bei einer mittelgroßen Anwendung — sagen wir 30 bis 50 Bildschirme mit Authentifizierung, Datenhaltung, Push und Offline-Modus — liegt der Entwicklungs-Aufwand für eine PWA typischerweise 40 bis 60 Prozent unter dem einer parallelen iOS-plus-Android-Entwicklung. Noch deutlicher wird der Vorteil in der Wartung: eine einzige Codebasis, ein Deployment, keine Store-Review-Zyklen für jeden Bugfix. Über drei Jahre Betrieb betrachtet halbieren sich die Gesamtkosten häufig.
Was ist mit Offline-Funktionen — funktioniert das wirklich zuverlässig?
Über Service-Worker und IndexedDB lassen sich auch komplexe Offline-Szenarien gut umsetzen — Lesezugriff, lokales Schreiben mit späterer Synchronisation, sogar große Datenmengen im hunderten Megabyte-Bereich. Die Browser-Engines sind hier seit 2024 sehr stabil. Die einzige relevante Einschränkung: Safari löscht Storage von PWAs, die länger als sieben Tage nicht benutzt wurden — für tägliche Tools kein Problem, für selten benutzte Apps schon.
Bereit, die richtige Mobile-Strategie zu wählen?
Sprechen wir 30 Minuten unverbindlich. Wir analysieren Ihren konkreten Anwendungsfall, prüfen die nötigen Capabilities und liefern eine klare Empfehlung mit Architektur-Skizze, realistischem Kostenrahmen und Zeitplan für die ersten 90 Tage.
30-minütiges Gespräch vereinbaren