Eine PWA (Progressive Web App) ist eine normale Web-App, die sich mit zwei Zusätzen wie eine installierte App verhält: einem Web-App-Manifest, das Name, Icon und Startseite festlegt, und einem Service Worker, der Anfragen abfängt und Inhalte für den Offline-Fall zwischenspeichert. Für die meisten internen Werkzeuge, Kundenportale und Praxis-Anwendungen reicht eine PWA. Eine native App lohnt sich erst, wenn du Hardware-Zugriff, Hintergrundprozesse oder einen Platz im App Store als Vertriebskanal brauchst.
Diese Entscheidung fällt besser vor dem ersten Angebot als nach dem ersten Release. Wer eine Web-App plant und "später noch eine App" im Hinterkopf hat, sollte die PWA-Frage in die Aufwandsschätzung aufnehmen, weil sie Architektur und Caching von Anfang an beeinflusst.
Was eine PWA technisch ausmacht
Eine Progressive Web App ist keine eigene Technologie, sondern eine Web-App mit festgelegten Zusatzbausteinen. Die Einführung der HTW Berlin beschreibt sie als "eine Webanwendung, die sich wie eine native mobile App verhält", und nennt den Service Worker als zentrales Konzept (HTW Berlin: Einführung Progressive Web Apps).
Das Web-App-Manifest
Das Manifest ist eine JSON-Datei (manifest.json oder manifest.webmanifest). Sie legt fest, wie die App nach der Installation erscheint: Name, Kurzname, Icons, Startseite, Hintergrundfarbe des Startbildschirms und Anzeigemodus. Ohne Manifest ist eine Web-App laut HTW-Kurs "noch nicht installierbar".
In der Praxis scheitert die Installation selten am Manifest selbst. Typischer Fehler: Die Icon-Größen fehlen. Microsoft verlangt für Power-Pages-PWAs zum Beispiel ein App-Symbol mit 512 × 512 Pixeln und weist darauf hin, dass iOS die Symbole als Miniaturansicht zeigt und den angepassten Startbildschirm nicht anzeigt (Microsoft Learn: Progressive Web-Apps erstellen und verteilen). Plane das Icon-Set also für beide Plattformen und prüfe den Startbildschirm auf einem echten iPhone, nicht nur im Desktop-Browser.
Der Service Worker
Der Service Worker ist ein Skript, das zwischen App und Netzwerk sitzt. Er entscheidet pro Anfrage, ob eine Antwort aus dem Cache oder vom Server kommt. Damit entstehen Offline-Fähigkeit und schnelle Wiederholungsaufrufe.
Der Service Worker ist auch die häufigste Fehlerquelle nach dem Go-live. Wer eine neue Version deployt und den Cache nicht versioniert, liefert Nutzern tagelang alte JavaScript-Dateien aus. Die Regel aus meinen Projekten: Jeder Cache-Name bekommt die Build-Version, und der Service Worker löscht beim Aktivieren alle Caches mit fremder Version.
Was im Browser bleibt
Eine PWA läuft weiterhin in der Browser-Engine des Geräts. Sie bekommt deshalb nur die Schnittstellen, die der jeweilige Browser freigibt. Welche das sind, unterscheidet sich zwischen Chrome auf Android, Safari auf iOS und Edge auf Windows. Prüfe jede Funktion, die dein Projekt braucht, vor dem Angebot auf den Zielgeräten deiner Nutzer.
PWA oder native App: Entscheidungsmatrix
Die Frage "App oder Browser?" lässt sich an sieben Kriterien entscheiden. Sobald eines davon in der rechten Spalte landet, ist eine reine PWA zu wenig.
| Kriterium | PWA reicht | Native App nötig |
|---|---|---|
| Vertrieb | Link, QR-Code, Login aus der Website | Sichtbarkeit in App-Store-Suche ist Teil des Vertriebs |
| Offline-Bedarf | Lesen von zuvor geladenen Ansichten | Umfangreiche Dateneingabe über Tage ohne Netz |
| Hardware | Kamera-Upload, Standort im Vordergrund | Bluetooth-Geräte, NFC, Sensoren im Hintergrund |
| Hintergrundausführung | Nicht nötig | Tracking oder Synchronisation bei geschlossener App |
| Updates | Sofort bei jedem Deploy | Store-Prüfung ist akzeptabel |
| Zielgruppe | Feste Nutzergruppe (Team, Patienten, Kunden) | Anonyme Endkunden, die im Store suchen |
| Budget | Eine Codebasis für Web, Android, iOS, Desktop | Budget für zwei Plattformen oder Cross-Platform-Framework |
Für ein Kundenportal im Mittelstand oder eine Terminübersicht für Praxen landen fast alle Kriterien links. Für eine Tracking-App, die Messgeräte per Bluetooth ausliest, landen mindestens zwei rechts. Bei der Basaltemperatur-App, einer Cross-Platform-Tracking-App, laufen eine SwiftUI-App für iOS und eine Next.js-Web-App nebeneinander und lesen dasselbe Supabase-Profil.
Zwischen beiden Welten gibt es einen Mittelweg: Eine PWA lässt sich als App-Paket in Stores bringen. Microsoft beschreibt dafür den Weg über PWABuilder, der Pakete für Android, iOS und Windows erzeugt; für Android kommt eine assetlinks.json hinzu, die den Besitz der Domain belegt (Microsoft Learn). Das löst das Vertriebsproblem, nicht aber fehlende Hardware-Schnittstellen.
Offline-Umfang: die Stelle, an der Budgets kippen
"Offline-fähig" klingt nach einem Häkchen in der Anforderungsliste. Tatsächlich gibt es zwei sehr unterschiedliche Stufen.
Stufe 1: Lesen ohne Netz
Der Service Worker speichert ausgewählte Seiten und Daten. Ohne Verbindung sieht der Nutzer den letzten Stand, alles Weitere zeigt eine Offline-Hinweisseite. Microsoft beschreibt genau dieses Modell: Ausgewählte Seiten sind offline schreibgeschützt verfügbar, Seiten mit Formularen oder Abfragen funktionieren offline nicht. Dazu kommt ein Detail, das in Anforderungen oft fehlt: Übersteigt der Speicherbedarf den freien Platz auf dem Gerät, ist laut Microsoft das gesamte Portal offline nicht verfügbar. Cache also nur Ansichten, die ohne Schreibzugriff einen echten Nutzen haben.
Stufe 2: Schreiben ohne Netz
Sobald Nutzer offline Daten eingeben, brauchst du eine lokale Warteschlange (meist IndexedDB), eine Synchronisation beim Wiederverbinden und eine Regel für Konflikte: Was passiert, wenn zwei Geräte denselben Datensatz offline geändert haben? Das ist kein Caching mehr, sondern verteilte Datenhaltung.
Meine Entscheidungsregel: Stufe 2 nur dann, wenn Nutzer nachweislich regelmäßig ohne Netz arbeiten, etwa im Außendienst im Keller oder auf Baustellen. "Könnte mal passieren" rechtfertigt den Aufwand nicht.
Beispielrechnung: Aufwand für eine PWA
Die folgenden Zahlen sind ein Rechenbeispiel, keine Preisangabe. Annahme: Eine bestehende Next.js-Web-App mit Login und drei Kernansichten soll installierbar werden und den letzten Stand offline anzeigen.
| Baustein | Stunden (Beispiel) |
|---|---|
| Manifest, Icon-Set, iOS-Meta-Tags | 2–4 |
| Service Worker mit versioniertem Cache | 6–10 |
| Offline-Hinweisseite und Fehlerzustände | 2–4 |
| Test auf Android, iOS, Desktop | 4–6 |
| Dokumentation und Übergabe | 2–4 |
| Summe | 16–28 |
Kommt Stufe 2 (Schreiben ohne Netz) für eine der drei Ansichten hinzu, verdoppelt sich im Beispiel der Testaufwand für genau diese Ansicht, weil jeder Konfliktfall einzeln durchgespielt werden muss. Eine zusätzliche native iOS-App mit denselben drei Ansichten liegt im selben Beispiel bei 120 bis 200 Stunden, plus Store-Einreichung und laufender Pflege für jede iOS-Version.
Wie man solche Spannen sauber in einen Festpreis übersetzt, zeigt die Aufwandsschätzung für Web-App-Festpreise mit der Drei-Punkt-Methode. Wer gerade ein erstes Produkt plant, findet die Kalkulation für den kleinsten sinnvollen Umfang unter Web-App-MVP: Kosten selbst kalkulieren.
Was bei PWA-Projekten typischerweise schiefgeht
- Veralteter Cache nach dem Deploy. Nutzer sehen alte Oberflächen, Support-Anfragen häufen sich. Früh erkennbar, wenn Tester nach einem Release noch die vorige Version sehen.
- Offline-Anforderung ohne Stufe. Im Angebot steht "offline-fähig", gemeint war Stufe 2, kalkuliert wurde Stufe 1. Klären, bevor ein Festpreis unterschrieben ist.
- Nur auf Android getestet. Installationsweg, Icons und Startbildschirm verhalten sich auf iOS anders. Ein echtes iPhone gehört in jeden Testlauf.
- Login-Seite im Cache. Wird eine authentifizierte Seite zwischengespeichert, kann nach dem Abmelden noch ein alter Stand sichtbar sein. Persönliche Daten deshalb nicht im Service-Worker-Cache ablegen, oder beim Logout den Cache leeren.
Häufige Fragen
Was ist ein PWA?
Eine PWA ist eine Web-App, die sich installieren lässt und mit Web-App-Manifest und Service Worker app-ähnlich startet, offline Inhalte anzeigt und schneller lädt. Sie läuft weiter in der Browser-Engine, braucht keinen App Store und wird bei jedem Deploy sofort aktualisiert.
Was ist besser, App oder Browser?
Das hängt an den Anforderungen, nicht am Geschmack. Brauchst du Bluetooth, Hintergrundausführung oder Sichtbarkeit in der Store-Suche, ist eine native App die passende Wahl. Für Portale, Dashboards und interne Werkzeuge reicht in den meisten Fällen eine PWA mit einer Codebasis.
Wie speichere ich eine Internetseite als App?
Öffne die Seite im Browser und wähle "Zum Startbildschirm hinzufügen" oder "App installieren"; die genaue Bezeichnung unterscheidet sich zwischen Android, iOS und Desktop-Browsern. App-ähnlich mit eigenem Fenster startet die Seite nur, wenn sie ein Web-App-Manifest mitbringt.
Wie erstelle ich eine Progressive Web App?
Du ergänzt eine bestehende Web-App um ein Manifest mit Name, Icons und Startseite und registrierst einen Service Worker, der festlegt, welche Inhalte im Cache landen. Danach testest du Installation und Offline-Verhalten auf allen Zielgeräten. In Next.js-Projekten ist das ein abgegrenztes Arbeitspaket, das sich gut einzeln schätzen lässt.
Funktioniert eine Progressive Web App auf Android?
Ja, Android-Nutzer können eine PWA über den Browser auf dem Startbildschirm installieren. Für den Vertrieb über den Play Store lässt sich die PWA zusätzlich als App-Paket verpacken; dafür muss die Domain per assetlinks.json als Eigentum nachgewiesen werden.