Eine Progressive Web App ist keine eigene Technologie, sondern eine normale Website mit drei Zusätzen: einer Manifestdatei, die Name und Symbol beschreibt, einem Hintergrunddienst für Zwischenspeicherung und Offline-Betrieb, und einer gesicherten Verbindung. Aus diesen drei Bausteinen entsteht etwas, das sich für den Nutzer wie eine installierte Anwendung verhält.
Was eine PWA tatsächlich kann
Der Abstand zur nativen App ist kleiner geworden, als viele Entscheider annehmen. Vier Eigenschaften decken den überwiegenden Teil typischer Anforderungen ab.
- Installation ohne Store: Symbol auf dem Startbildschirm, eigener Fensterrahmen ohne Browserleiste.
- Offline-Betrieb: zwischengespeicherte Inhalte bleiben ohne Verbindung nutzbar.
- Push-Nachrichten: auf allen relevanten Plattformen inzwischen möglich, auf Apple-Geräten allerdings erst nach Installation auf den Startbildschirm.
- Gerätezugriff: Kamera, Standort, Dateien und Bewegungssensoren stehen im Rahmen der Browserberechtigungen zur Verfügung.
Damit sind die häufigsten Anwendungsfälle abgedeckt: Kundenportale, Buchungsoberflächen, interne Werkzeuge, Bestellsysteme, Dokumentationsanwendungen im Außendienst.
Der unterschätzte Vorteil ist nicht die Technik, sondern die Verteilung. Eine PWA wird über einen Link geöffnet — kein Store, keine Prüfung, keine Installation vor der ersten Nutzung. Genau an dieser Hürde verliert eine native App den größten Teil der potenziellen Nutzer.
Wo die Grenzen wirklich liegen
Es gibt Anforderungen, bei denen eine PWA nicht ausreicht. Sie sind konkret benennbar und sollten zu Beginn geprüft werden, statt sie im Projektverlauf zu entdecken.
- Dauerhafter Hintergrundbetrieb: etwa laufende Standortaufzeichnung oder ständige Bluetooth-Verbindung.
- Tiefe Systemintegration: Zugriff auf Kontakte, Kalender oder systemweites Teilen in vollem Umfang.
- Spezialhardware: bestimmte Nahfeldfunktionen und proprietäre Peripherie.
- Rechenintensive Grafik: aufwendige 3D-Anwendungen und Spiele.
- Store-Präsenz als Vertriebskanal: wenn Nutzer das Produkt tatsächlich im Store suchen.
Der letzte Punkt ist eine Marketing-, keine Technikfrage — und trotzdem oft der ausschlaggebende. Bei einer Anwendung für Bestandskunden spielt er keine Rolle; bei einem Endkundenprodukt kann er entscheidend sein.
Die Kostenrechnung
Der wirtschaftliche Unterschied entsteht nicht bei der Erstentwicklung, sondern in der Pflege. Eine native Lösung bedeutet in der Regel zwei getrennte Anwendungen für zwei Plattformen, dazu die Website, die ohnehin existiert — also drei Stränge, die bei jeder Änderung gepflegt, getestet und ausgerollt werden.
Eine PWA ist ein Strang. Änderungen sind sofort für alle Nutzer wirksam, ohne Store-Prüfung und ohne dass jemand ein Update installieren muss. Bei einem Werkzeug, das mehrfach im Monat angepasst wird, ist das nicht nur billiger, sondern qualitativ ein anderer Betrieb — es gibt keine veralteten Installationen im Feld.
Was die Umsetzung praktisch verlangt
Eine bestehende Website wird nicht durch das Hinzufügen einer Manifestdatei zur brauchbaren Anwendung. Drei Punkte entscheiden über das Ergebnis.
Erstens die Zwischenspeicherstrategie: Was wird dauerhaft vorgehalten, was immer frisch geladen, und was darf im Notfall veraltet ausgeliefert werden? Eine falsch konfigurierte Strategie führt dazu, dass Nutzer wochenlang eine alte Version sehen — der häufigste und ärgerlichste Fehler in diesem Bereich.
Zweitens das Verhalten ohne Verbindung: Eine Anwendung, die offline eine Fehlerseite zeigt, hat den Zweck verfehlt. Es braucht einen definierten Zustand mit den zuletzt bekannten Daten und einem klaren Hinweis, dass gerade keine Verbindung besteht.
Drittens die Bedienbarkeit auf dem Gerät: Ohne Browserleiste fehlt die gewohnte Zurück-Navigation, Ladezustände müssen sichtbar sein und Berührungsflächen ausreichend groß. Die Grundlagen dazu beschreibt der Beitrag zu Mobile First.
Der pragmatische Weg
In der Praxis bewährt sich eine Reihenfolge: zuerst die Website als PWA ausbauen, den tatsächlichen Nutzungsverlauf messen und erst dann entscheiden, ob eine native App überhaupt nötig ist.
Diese Reihenfolge kostet wenig und liefert eine Antwort, die vorher niemand hat: Wie viele Nutzer installieren die Anwendung überhaupt, welche Funktionen werden genutzt und an welcher Stelle stößt die Weblösung an eine echte Grenze? Wird nach einigen Monaten trotzdem nativ gebaut, ist die Anforderungsliste dann belegt statt vermutet — und der PWA-Aufwand war keine Fehlinvestition, weil die Website davon dauerhaft profitiert.
Dass die Website mitprofitiert, ist dabei kein Nebeneffekt, sondern der zweite wirtschaftliche Grund für diesen Weg. Zwischenspeicherung und ein bewusst gestaltetes Verhalten bei schlechter Verbindung verbessern die Ladezeit für alle Besucher — auch für die, die nie etwas installieren. Der Aufwand zahlt also auf zwei Ziele gleichzeitig ein.
Wichtig ist nur, die Installation aktiv anzubieten statt darauf zu warten, dass jemand sie im Browsermenü findet. Ein dezenter Hinweis nach der zweiten oder dritten Nutzung — wenn der Wert bereits erlebt wurde — funktioniert deutlich besser als ein Banner beim ersten Aufruf, der wie eine Störung wirkt und weggeklickt wird.