Progressive Web Apps (PWA): Die Brücke zwischen Website und nativer App
Sie möchten Ihre Inhalte oder Ihren Service auf dem Smartphone Ihrer Nutzer präsent haben, scheuen aber den Aufwand und die Kosten zweier nativer Apps für iOS und Android? Genau hier setzen Progressive Web Apps an. Eine PWA ist eine Website, die sich wie eine installierte App verhält: Sie liegt mit eigenem Icon auf dem Homescreen, funktioniert auch ohne Internetverbindung und kann Push-Benachrichtigungen senden. In diesem Artikel erkläre ich Ihnen, was eine PWA technisch ausmacht, was sie kann und wo ihre Grenzen liegen. Außerdem erfahren Sie, wann eine PWA die richtige Wahl ist und wann Sie doch besser zur nativen App greifen sollten. Stand: 2026.
Was ist eine Progressive Web App?
Eine Progressive Web App ist im Kern eine ganz normale Website, die mit modernen Webtechnologien zusätzliche Fähigkeiten erhält, die man bislang nur von nativen Apps kannte. Der Nutzer ruft sie wie jede andere Seite über den Browser auf. Erfüllt die Seite bestimmte technische Voraussetzungen, bietet der Browser an, sie zum Homescreen hinzuzufügen. Ab diesem Moment fühlt sie sich an wie eine echte App: Sie startet mit eigenem Icon, öffnet sich im Vollbildmodus ohne sichtbare Browserleiste und läuft auch dann, wenn gerade keine Verbindung besteht.
Der Begriff „progressive“ beschreibt das Grundprinzip dahinter, das sogenannte Progressive Enhancement. Die Anwendung funktioniert auf jedem Gerät und in jedem Browser als Website. Auf modernen Geräten und in unterstützenden Browsern kommen dann schrittweise zusätzliche Funktionen hinzu. Ein Nutzer mit einem älteren Smartphone bekommt die Website, ein Nutzer mit aktuellem Gerät zusätzlich Offline-Fähigkeit, Installierbarkeit und Benachrichtigungen. Niemand wird ausgeschlossen, jeder bekommt die bestmögliche Erfahrung für sein Gerät.
Hinweis: Der Begriff „Progressive Web App“ wurde 2015 von Google-Entwickler Alex Russell und der Designerin Frances Berriman geprägt. Eine PWA ist kein festes Produkt und kein bestimmtes Framework, sondern eine Sammlung von Best Practices und Webstandards, die zusammen eine app-ähnliche Erfahrung im Browser ermöglichen.
Wichtig ist die Einordnung zwischen den beiden Welten. Eine klassische Website lebt im Browser-Tab, ist über Google auffindbar und erfordert keine Installation, kann aber nicht offline arbeiten und sich nicht in den Hintergrund integrieren. Eine native App wird über den App Store installiert, hat vollen Zugriff auf die Hardware, muss aber für jede Plattform separat entwickelt werden. Eine PWA schlägt eine Brücke zwischen beiden: Sie kombiniert die Reichweite und Einfachheit des Webs mit vielen Annehmlichkeiten einer App.
Die drei Kerntechnologien einer PWA
Damit aus einer gewöhnlichen Website eine Progressive Web App wird, braucht es im Wesentlichen drei technische Bausteine. Diese Bausteine arbeiten zusammen und ergeben erst in ihrer Kombination das app-ähnliche Erlebnis. Ich erkläre Ihnen jeden einzeln, ohne Sie mit Code zu überfrachten.
Der Service Worker
Der Service Worker ist das Herzstück jeder PWA. Es handelt sich um ein kleines JavaScript-Programm, das unabhängig von der eigentlichen Website im Hintergrund des Browsers läuft. Er sitzt sozusagen als Vermittler zwischen Ihrer Anwendung und dem Netzwerk. Jede Anfrage, die die App ans Internet schickt, läuft durch den Service Worker. Dadurch kann er entscheiden, ob eine Datei aus dem Netz geladen oder aus einem lokalen Zwischenspeicher bedient wird.
Genau diese Vermittlerrolle macht die wichtigsten PWA-Funktionen erst möglich. Der Service Worker ermöglicht die Offline-Nutzung, weil er Inhalte vorhält. Er empfängt Push-Nachrichten, auch wenn die App gerade nicht geöffnet ist. Und er kann Daten im Hintergrund synchronisieren, sobald wieder eine Verbindung besteht. Da er außerhalb der Website läuft, bleibt er aktiv, selbst wenn der Nutzer den Tab geschlossen hat.
Das Web App Manifest
Das Web App Manifest ist eine kleine Konfigurationsdatei im JSON-Format. In ihr legen Sie fest, wie sich Ihre App verhält, wenn sie installiert wird. Hier definieren Sie den Namen der App, das Icon für den Homescreen, die Hintergrund- und Designfarben sowie den Anzeigemodus. Der wichtigste Eintrag ist der Anzeigemodus, oft auf „standalone“ gesetzt. Er sorgt dafür, dass die App ohne Browserleiste im Vollbild startet und damit wie eine echte App wirkt.
Ohne ein korrektes Manifest bietet der Browser die Installation gar nicht erst an. Gerade auf iOS ist das Manifest besonders wichtig: Apple verlangt für viele Funktionen, dass die App als „Home Screen web app“ über das Manifest deklariert ist. Fehlt der Eintrag „display: standalone“, taucht beispielsweise die Push-API auf iPhones erst gar nicht im Service Worker auf, selbst wenn technisch alles andere korrekt eingerichtet ist.
HTTPS als Pflicht
Die dritte unverzichtbare Voraussetzung ist HTTPS, also eine verschlüsselte Verbindung. Service Worker und Push-API funktionieren ausschließlich über HTTPS, ohne jede Ausnahme. Der Grund ist Sicherheit: Da der Service Worker Netzwerkanfragen abfangen und verändern kann, wäre er über eine unverschlüsselte Verbindung ein gefährliches Einfallstor für Angreifer. Bereits eine Weiterleitung von HTTP auf HTTPS kann die Registrierung des Service Workers stören. Deshalb muss die gesamte Seite inklusive aller eingebundenen Dateien konsequent über HTTPS ausgeliefert werden. Für lokale Entwicklung ist „localhost“ als sichere Ausnahme zugelassen.
Praxis-Tipp: Sie müssen eine PWA nicht von Grund auf neu schreiben. In den meisten Fällen reicht es, eine bestehende, sauber gebaute Website um Service Worker und Manifest zu erweitern. Mit dem kostenlosen Lighthouse-Audit in den Chrome DevTools prüfen Sie in wenigen Sekunden, ob Ihre Seite die PWA-Kriterien erfüllt und wo es noch hakt.
Was Progressive Web Apps können
Die Theorie hinter PWAs ist das eine, der konkrete Nutzen für Ihre Anwender das andere. Drei Fähigkeiten machen den entscheidenden Unterschied zur klassischen Website aus und sorgen dafür, dass eine PWA als ernsthafte Alternative zur nativen App gilt.
Offline-Fähigkeit und Caching
Dank des Service Workers funktioniert eine PWA auch ohne Internetverbindung. Beim ersten Besuch legt der Service Worker wichtige Dateien wie HTML, Stylesheets, Skripte und Bilder in einem lokalen Zwischenspeicher ab. Ruft der Nutzer die App später ohne Verbindung auf, liefert der Service Worker diese Inhalte aus dem Cache aus. Statt der frustrierenden Fehlermeldung des Browsers sieht der Nutzer also die App oder zumindest eine sinnvolle Offline-Seite.
Für das Caching gibt es verschiedene Strategien, die Sie je nach Inhalt wählen. Bei „Cache First“ wird zuerst der Zwischenspeicher abgefragt, was maximale Geschwindigkeit bringt und sich für statische Inhalte eignet. Bei „Network First“ wird zuerst das Netzwerk versucht und nur bei Ausfall auf den Cache zurückgegriffen, was für dynamische, aktuelle Daten sinnvoll ist. Diese Flexibilität sorgt nicht nur für Offline-Tauglichkeit, sondern macht die App auch bei schlechter Verbindung spürbar schneller.
Installierbarkeit ohne App Store
Eine PWA lässt sich direkt aus dem Browser heraus auf dem Gerät installieren, komplett ohne Umweg über einen App Store. Unter Android und auf dem Desktop bietet der Browser dafür meist aktiv einen Installations-Button an. Nach der Installation liegt das App-Icon auf dem Homescreen, im App-Drawer oder im Startmenü, genau wie bei einer nativen App. Der Nutzer öffnet sie mit einem Fingertipp, ohne Browser, ohne Adresszeile.
Auf dem iPhone war dieser Vorgang lange weniger intuitiv. Hier muss der Nutzer in Safari über das Teilen-Menü den Eintrag „Zum Home-Bildschirm“ auswählen, ohne dass ein deutlicher Hinweis erscheint, dass die Seite überhaupt eine PWA ist. Seit iOS 26 hat Apple das immerhin vereinfacht: Jede zum Homescreen hinzugefügte Website öffnet sich nun standardmäßig als eigenständige Web-App, sogar ohne Manifest-Datei. Der manuelle Installationsweg über das Teilen-Menü bleibt auf iOS aber bestehen.
Push-Benachrichtigungen
Push-Benachrichtigungen waren lange das stärkste Argument für native Apps, weil sie Nutzer aktiv zurückholen. Mittlerweile beherrschen auch PWAs diese Funktion. Über die Push-API und den Service Worker kann eine installierte PWA Benachrichtigungen empfangen und anzeigen, selbst wenn die App geschlossen ist. Voraussetzung ist immer, dass der Nutzer ausdrücklich zugestimmt hat.
Unter Android funktionieren Push-Nachrichten seit Jahren zuverlässig. Auf iOS hat Apple mit iOS 16.4 im Jahr 2023 nachgezogen und Web-Push für PWAs eingeführt. Allerdings gilt auf dem iPhone eine wichtige Einschränkung: Push-Benachrichtigungen funktionieren nur, wenn die PWA zuvor zum Homescreen hinzugefügt wurde. Eine im Safari-Tab geöffnete PWA bekommt keine Pushes. Zudem darf die Berechtigungsabfrage auf iOS ausschließlich durch eine echte Nutzeraktion ausgelöst werden, etwa einen Button-Klick. Wird sie automatisch beim Laden aufgerufen, blockiert iOS sie kommentarlos.
Hinweis: Die Zustellrate von Push-Nachrichten liegt auf iOS nach Berichten erfahrener Teams bei etwa 70 bis 85 Prozent, auf Android bei rund 90 bis 95 Prozent. Der Unterschied ergibt sich aus Safaris strengerem Umgang mit Hintergrundprozessen. Mit Safari 18.4 hat Apple zudem „Declarative Web Push“ eingeführt, eine vereinfachte Variante, die in einfachen Fällen ganz ohne Service Worker auskommt.
PWA, native App und klassische Website im Vergleich
Um die Einordnung zu erleichtern, stelle ich Ihnen die drei Ansätze direkt gegenüber. Die folgende Tabelle zeigt die wichtigsten Unterschiede auf einen Blick, von der Entwicklung über den Hardwarezugriff bis zur Auffindbarkeit.
| Kriterium | Klassische Website | Progressive Web App | Native App |
|---|---|---|---|
| Codebasis | Eine (Web) | Eine (Web) | Je Plattform eine |
| Installation | Keine | Direkt aus dem Browser | Über App Store |
| Offline-Nutzung | Nein | Ja, per Caching | Ja |
| Push-Benachrichtigungen | Eingeschränkt | Ja (iOS nur nach Installation) | Ja, vollständig |
| Hardwarezugriff | Sehr begrenzt | Begrenzt, auf iOS stärker eingeschränkt | Voll |
| Auffindbar über Google | Ja | Ja | Nein, nur App Store |
| Entwicklungskosten | Niedrig | Niedrig bis mittel | Hoch |
| Updates | Sofort | Sofort | Über Store-Prüfung |
| App-Store-Gebühren | Keine | Keine | Bis zu 30 Prozent |
Die Tabelle macht die Position der PWA deutlich. Sie übernimmt die Stärken der Website, also eine Codebasis, sofortige Updates und Auffindbarkeit über Suchmaschinen, und ergänzt sie um zentrale App-Funktionen. Den vollständigen Funktionsumfang einer nativen App erreicht sie nicht, kommt ihm in vielen Anwendungsfällen aber sehr nahe.
Die Vorteile einer PWA
Die größten Argumente für eine PWA liegen in den Bereichen Kosten, Reichweite und Wartung. Gerade für Unternehmen, die noch keine eigene App haben und den Aufwand zweier nativer Apps scheuen, ist das oft der entscheidende Hebel.
Dass diese Vorteile keine Theorie sind, zeigen prominente Beispiele. Twitter Lite erreichte mit seiner PWA 65 Prozent mehr Seiten pro Sitzung und senkte die Absprungrate um 20 Prozent, bei unter drei Prozent des Datenverbrauchs der nativen App. Pinterest steigerte die Kernnutzung um 60 Prozent und verzeichnete deutlich mehr Anmeldungen über das mobile Web. Tinder reduzierte die Ladezeit von 11,9 auf 4,7 Sekunden und machte den Dienst in Regionen mit schlechter Anbindung zugänglich. Auch Starbucks und Spotify setzen seit Jahren erfolgreich auf PWA-Technologie.
Die Grenzen einer PWA
So überzeugend die Vorteile sind, eine PWA ist kein vollwertiger Ersatz für eine native App. Die Einschränkungen liegen vor allem beim Hardwarezugriff und, das muss man ehrlich sagen, bei Apples Plattform iOS. Wer diese Grenzen kennt, trifft eine bessere Entscheidung.
Eingeschränkter Hardwarezugriff
Eine PWA kann auf viele Gerätefunktionen zugreifen, etwa Kamera, Standort, Mikrofon oder Geräteausrichtung. Bei tiefergehenden Hardwarefunktionen stößt sie aber an Grenzen. Web Bluetooth funktioniert zwar in Chrome und Edge, ist auf iOS jedoch blockiert. NFC, fortgeschrittene Sensor-Schnittstellen oder die Integration in Gesundheitsdaten wie Apples HealthKit bleiben native App-Domäne. Auch die biometrische Anmeldung per Face ID oder Touch ID lässt sich nur eingeschränkt nutzen.
Die iOS- und Safari-Einschränkungen
Während Android nahezu den vollen PWA-Funktionsumfang bietet, hinkt iOS weiterhin hinterher. Safari unterstützt kein Background Sync, das bedeutet, eine PWA kann auf dem iPhone keine Daten im Hintergrund synchronisieren oder Inhalte vorab laden, bevor der Nutzer sie öffnet. Hinzu kommt eine restriktive Speicherverwaltung: Safari kann zwischengespeicherte PWA-Daten nach längerer Inaktivität löschen. Ein Nutzer, der Ihre PWA eine Weile nicht geöffnet hat, findet seinen gespeicherten Warenkorb oder seine Einstellungen unter Umständen geleert vor.
Eine technische Besonderheit verstärkt das: Auf iOS müssen alle Browser, auch Chrome oder Firefox, im Hintergrund Apples WebKit-Engine nutzen. Es gibt also faktisch nur einen Browserunterbau, und der gibt den Funktionsrahmen vor. Rund um den EU Digital Markets Act gab es 2024 und 2025 ein Hin und Her: Apple hatte die PWA-Unterstützung in der EU zeitweise entfernt, nach heftiger Kritik aber wieder eingeführt. Im April 2025 verhängte die EU eine Strafe von 500 Millionen Euro wegen Verstößen gegen den DMA. Praktisch hat sich an dem, was Sie heute mit einer PWA auf dem iPhone bauen können, dadurch aber nichts Grundlegendes geändert.
Hinweis: Wenn Ihre Zielgruppe stark auf dem iPhone vertreten ist und Sie zwingend auf Background Sync, NFC, Web Bluetooth oder persistente Offline-Daten angewiesen sind, sollten Sie eine native oder hybride Lösung ernsthaft prüfen. Für die meisten inhalts- und transaktionsorientierten Anwendungen reichen die PWA-Funktionen auf iOS jedoch völlig aus.
Wann ist eine PWA die richtige Wahl?
Die Entscheidung zwischen PWA und nativer App hängt von Ihren konkreten Anforderungen ab. Es gibt klare Szenarien, in denen eine PWA ihre Stärken voll ausspielt, und solche, in denen eine native Lösung unverzichtbar bleibt.
Eine PWA ist sinnvoll bei
Eine native App ist oft die bessere Wahl bei
Zwischen den beiden Extremen gibt es noch einen dritten Weg: hybride oder Cross-Platform-Ansätze. Frameworks wie Flutter oder React Native erlauben es, mit einer weitgehend gemeinsamen Codebasis echte native Apps für beide Plattformen zu bauen. Sie liegen damit funktional zwischen PWA und vollständig nativer Entwicklung. Welcher Weg der richtige ist, lässt sich am besten im Gespräch über Ihre konkreten Ziele klären, etwa im Rahmen einer App-Entwicklung.
Meine Praxis-Empfehlung
Aus meiner Erfahrung lohnt es sich, das Projekt nicht von der Technologie, sondern von der Nutzersituation her zu denken. Fragen Sie sich: Wie kommt mein Nutzer typischerweise zu meinem Angebot? Sucht er bei Google nach einer Lösung, ist eine PWA fast immer überlegen, weil sie ohne Installationshürde direkt erreichbar ist. Ist Ihr Angebot dagegen etwas, das Nutzer bewusst und langfristig auf ihrem Gerät behalten wollen, kann die App-Store-Präsenz einer nativen App ihren Wert haben.
In vielen Projekten empfehle ich einen pragmatischen Mittelweg: Starten Sie mit einer PWA. Sie ist schneller umgesetzt, günstiger und auf allen Plattformen verfügbar. So validieren Sie Ihre Idee am echten Markt, ohne sofort das volle Budget zweier nativer Apps zu binden. Stellt sich später heraus, dass Sie eine bestimmte native Funktion zwingend brauchen, können Sie gezielt nachrüsten. Diese stufenweise Strategie minimiert das Risiko und hält Ihnen alle Optionen offen.
Praxis-Tipp: Bewerten Sie eine PWA nicht danach, ob sie alles kann, was eine native App kann. Bewerten Sie sie danach, ob sie alles kann, was Ihr konkretes Projekt braucht. In der überwiegenden Mehrheit der inhalts- und serviceorientierten Projekte, die mir begegnen, lautet die Antwort: ja, und das zu einem Bruchteil der Kosten.
Fazit
Progressive Web Apps schlagen eine echte Brücke zwischen klassischer Website und nativer App. Mit Service Worker, Web App Manifest und HTTPS als Fundament bieten sie Offline-Fähigkeit, Installierbarkeit und Push-Benachrichtigungen, also genau jene Funktionen, die lange den nativen Apps vorbehalten waren. Ihr größter Trumpf bleibt die eine Codebasis für alle Plattformen, kombiniert mit der Auffindbarkeit des Webs und ohne App-Store-Zwang.
Die Grenzen liegen vor allem beim tiefen Hardwarezugriff und bei einigen iOS-spezifischen Einschränkungen wie fehlendem Background Sync. Für die große Mehrheit der inhalts- und serviceorientierten Projekte sind diese Grenzen jedoch nicht entscheidend. Meine Empfehlung: Prüfen Sie ehrlich, welche Funktionen Ihr Projekt wirklich braucht. In sehr vielen Fällen ist die PWA die schnellere, günstigere und reichweitenstärkere Lösung, ohne dass Sie auf das App-Erlebnis verzichten müssen.
Eine PWA für Ihr Projekt?
Sie überlegen, ob eine Progressive Web App für Ihr Vorhaben die richtige Lösung ist? Ich berate Sie gerne und begleite Sie von der Konzeption über die Architektur bis zur fertigen Umsetzung.
