PWAs: Web-Apps mit Superkräften. Flexibel, schnell, installierbar.

PWAs vereinen das Beste aus klassischer nativer App-Entwicklung und moderner Web-App-Entwicklung. In diesem Text bekommst du einen Überblick: Was PWAs sind (und was nicht), warum sie sich lohnen, wo die Grenzen liegen: plus ein Praxisbeispiel aus unserem Alltag und handfeste Lessons Learned.

Was ist eine PWA?

Du weisst schon was eine PWA ist? Hier geht direkt zur Case Study mit den technischen Details.

Kurz gesagt: PWAs sind Webanwendungen, die moderne Webtechnologien nutzen, um wie native Apps zu wirken: auf Mobile und Desktop.

Je nach Bedarf können PWAs:

• Installierbar sein: Mit App-Icon, Splashscreen und Vollbildmodus.
• Offline funktionieren: Perfekt für schlechten Empfang im Lager oder Zug.
• Betriebssystem-Features nutzen: Wie Push-Benachrichtigungen oder Hintergrund-Synchronisation, soweit plattformseitig verfügbar.
• Direkt im Browser verfügbar: Keine Barriere durch einen App-Store und alle User haben immer die aktuellste Version - ohne Updates. PWAs sind wie jede Website über eine URL erreichbar und damit auch für Suchmaschinen optimierbar.

Auch grosse Unternehmen setzen auf PWA’s. Starke Beispiele sind zum Beispiel:

Starbucks: Dank PWA Funktionalitäten ist die Starbucks-App auch offline verfügbar, damit Kund:innen ihren Warenkorb anlegen können, selbst wenn sie gerade keinen Empfang haben.

Pinterest: Die Neugestaltung ihrer mobilen Website als PWA führte zu einer Steigerung der Conversion-Rate um 40 % und einer 60 % höheren Engagement-Rate.

Uber: Ihre PWA ermöglicht es Nutzer:innen mit langsamen Internetverbindungen, ihre Fahrten schnell zu buchen. Die App ist nur 50 KB gross und in weniger als 3 Sekunden geladen.

Warum (noch) keine PWA?

Hardware-/OS-APIs teilweise eingeschränkt
Je nach Plattform sind manche nativen Features (z. B. bestimmte Bluetooth-/NFC-Funktionen) limitiert.

App-Store-Integration ist noch nicht ganz reif
Das Packaging für Microsoft Store und Google Play ist gut machbar (z. B. via PWABuilder). Der iOS App Store ist möglich, aber noch experimentell.

Die Seite https://whatpwacando.today/ zeigt mit Demos, was PWAs können und was nicht.

Technische Lessons Learned

Offlinefähigkeit 1: Daten-Caching bewusst gestalten

Daten-Layer: TanStack React Query. Mit @tanstack/query-sync-storage-persister schreibt der Query Client seine Daten in den localStorage. So sind sie auch offline verfügbar. Für veraltete Daten sorgt ein Buster-Parameter bei Schema-Änderungen für die Cache-Invalidierung.

Wichtig: Aufräumen nicht vergessen: Wer in localStorage schreibt, muss alte Schlüssel aktiv löschen, wenn sie nicht mehr gebraucht werden.

Offlinefähigkeit 2: Caching der App selbst (Service Worker)

Einige typische Strategien sind:

Network only: Hierbei wird komplett auf ein lokales Caching verzichtet.

Cache Only: Die App liefert Ressourcen nur aus dem Cache und geht gar nicht ins Netz. Gut für statische Assets wie Logos oder Schriftarten.

Network First, falling back to cache: Zuerst wird versucht, die Ressource aus dem Netz zu laden. Wenn das fehlschlägt, wird der Cache als Fallback genutzt. Ideal für Inhalte, die so aktuell wie möglich sein müssen.

Cache First, falling back to network: Zuerst wird im Cache gesucht. Nur wenn die Ressource dort nicht gefunden wird, geht die App ins Netz. Eine gute Wahl für Ressourcen, die nicht ständig aktualisiert werden müssen.

Stale-while-revalidate: Die App liefert die Ressource sofort aus dem Cache und holt gleichzeitig im Hintergrund die aktuellste Version aus dem Netz, um den Cache für das nächste Mal zu aktualisieren.

Eine «Network first, falling back to cache» Strategie passt hier gut: Nutzer:innen bekommen immer die aktuellen Daten, und bei Offline-Funktionen fällt die App robust auf den Cache zurück.

App-Updates und Versionierung

Eine PWA lädt nicht immer sofort den neuesten Build, während die dynamisch geladenen JSON-Daten vom Backend schon aktuell sind. Das führt zu einem Problem: Der Client muss alte Schemata tolerieren. Oder aber, du zwingst ein Update, sobald es Breaking Changes gibt.

Unser Setup:

Bei App-Start wird die Versionsnummer vom Server abgefragt.

Wenn du offline bist, sind die lokale und Remote-Version identisch, also wird nichts getan.

Wenn du online bist und die lokale Versionsnummer von der Remote-Version abweicht, wird ein Reload erzwungen. So laden die Nutzer:innen immer den neuesten Build.

Zusätzlich nutzen wir:

Die SCHEMA_VERSION im clientseitigen API-Layer als Buster.

Eine Abfrage der Versionsnummer, die nicht gecacht wird (z. B. GET /VERSION?${Date.now()}), damit die aktuelle Version garantiert ankommt.

Die window.matchMedia und display-mode Funktion, um zwischen der installierten App und der Browser-Version zu unterscheiden, falls du beide Varianten nutzt. So wird sichergestellt, dass beide korrekt aktualisiert werden.

Splashscreens für iOS und Android

pwa-asset-generator erzeugt Splashscreens und Icons in allen Grössen für alle Geräte und Betriebssysteme: aus einem Basis-Icon.

Bonus: Symfony-Stack

Für Symfony gibt es das PWA-Bundle von Spomky-Labs. Noch jung, aber bereits hilfreich für Manifest, Service Worker und Co. Ein pragmatischer Weg, wenn du im Symfony-Ökosystem unterwegs bist.