Progressive Web App (PWA)

Du brauchst 3 Dinge:

1. HTTPS: Bedingung für Sicherheit.
2. Manifest.json: Eine Datei mit Icon, Name, Farben. ("Wie sehe ich als App aus?").
3. Service Worker: Ein Skript, das im Hintergrund läuft und das Netzwerk kontrolliert (siehe nächster Begriff).

1. Project Fugu

Google's Initiative, dem Web alle Fähigkeiten von nativen Apps zu geben.

• Bluetooth Zugriff? Ja.
• Dateisystem Zugriff? Ja.
• USB Zugriff? Ja. Apple (iOS) bremst das oft (um den App Store zu schützen), aber Android und Desktop (Chrome) sind sehr weit.

2. TWA (Trusted Web Activity)

Du kannst deine PWA in den Google Play Store packen. Es ist eine dünne Hülle um deine Webseite. Vorteil: Du wirst im Store gefunden, musst aber nicht Java/Kotlin lernen.

1. Service Worker Lifecycle & "Wait to Update" Hell

Der absolute Albtraum in PWA-Production ist das Cache-Invalidierungs-Verhalten von Service Workern. Ein Service Worker installiert sich, lädt Assets (HTML, JS, CSS) in die Cache Storage API, und serviert sie ab sofort netzwerkfrei. Deployt der Entwickler eine neue Version v2.js, lädt der Browser den neuen Worker im Hintergrund runter (install-Event). Aber: Er wird in den Zustand "Waiting" versetzt! Der alte Worker behält gnadenlos die Kontrolle, bis alle Browser-Tabs der App geschlossen sind! Einfaches Neuladen (F5) reicht nicht. Das führt dazu, dass User auf einer veralteten SPA-Version festsitzen, wo API-Endpoints abwärtsinkompatibel brechen. Profis lösen das zwingend über einen UI-Refresh Banner ("Neue Version verfügbar") kombiniert mit worker.postMessage({type: 'SKIP_WAITING'}), das den wartenden Worker zwingt, den alten aggressiv im laufenden Tab zu ermorden.

2. Die Cache API vs HTTP-Cache

Browser haben bereits einen HTTP-Cache. Die PWA bringt die programmatische Cache Storage API. Das sind zwei völlig isolierte Layer! Der Service Worker (fetch Event Listener) steht vor dem HTTP-Cache. Wenn die PWA das Caching nach dem Stale-While-Revalidate Muster implementiert (z.B. mit Google's Workbox-Bibliothek), serviert der Worker die Millisekunden-alte Datei aus dem PWA Cache. Parallel sendet er einen Request ans Internet. Das perfide: Dieser Background-Request verfängt sich oft im regulären Browser-HTTP-Cache, wenn die Cache-Control Header des Servers falsch gesetzt sind! Workbox updatet dann seinen PWA-Cache mit einem bereits "stale" Asset aus dem Browser HTTP Cache. PWA-Experten setzen daher die HTTP Cache Header bei Service-Worker verwalteten Apps oft radikal auf no-cache, um diese fatale Cache-Hierarchie-Dopplung zu zerschlagen.

3. Background Sync & Periodic Sync

Eine echte native App (wie WhatsApp) schickt die formulierte Nachricht asynchron weg, sobald der Zug wieder aus dem Tunnel fährt. PWAs beherrschen dies mittels der Background Sync API. Bist du offline und drückst "Senden", speichert das Frontend den JSON Payload in die IndexedDB. Danach feuert es via Service Worker registration.sync.register('sync-chat'). Du kannst den Mobile Browser nun komplett beenden (!). Sobald das OS (Android) eine offene WLAN-Verbindung triggert, erweckt es den Service Worker geräuschlos im Hintergrund. Dieser ruft das sync Event der PWA auf, liest die IndexedDB iterativ aus und pusht die Messages ans Backend.