Was ist eine PWA (Progressive Web App)?

Eine PWA ist eine Web-App, die mit Service Worker, Manifest und HTTPS installierbar wird, offline funktioniert und Push-Benachrichtigungen empfängt. Den Begriff prägten Alex Russell und Frances Berriman 2015: Er beschreibt, was den Abstand zwischen einer Website und einer installierten App schließt, ohne das Web zu verlassen – eine Codebasis, ein Icon auf dem Startbildschirm, ein eigenständiges Fenster und ein Bildschirm, der weiterarbeitet, wenn der Zug in den Tunnel fährt. Der Blickwinkel, den dieses Glossar ergänzt und den Frontend-Erklärungen auslassen: Eine PWA bleibt ein Client – der Service Worker cacht, aber Ihr Backend ist die Quelle der Wahrheit.

Das Wichtigste in Kürze

Die drei Säulen und das Backend dahinter

// JavaScript — the PWA's three pillars + the backend behind them
// 1 · Service worker: caches the shell, buffers writes when offline
navigator.serviceWorker.register('/sw.js');

// 2 · Manifest (public/manifest.json) makes it installable:
//    { "name": "Notes", "display": "standalone", "start_url": "/", "icons": [...] }

// 3 · HTTPS is required — service workers refuse to run otherwise.

// The catch: the SW cache is a MIRROR, not the source of truth.
// saveEventually() stores the write offline and sends it when back online:
const note = new Parse.Object('Note').set('text', draft);
await note.saveEventually(); // the BaaS is authoritative; the cache was a buffer

// Flutter / Dart — Back4app Flutter SDK (Flutter web compiles to a PWA)
// The service worker caches the app shell; data still lives on the backend.
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Offline-first pattern: write locally, queue, and sync when connectivity
// returns — the API/BaaS is the source of truth, the cache is a local mirror.
// Push notifications need a BACKEND to send them; the client only subscribes.

// Swift — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
var note = Note()
note.text = draft
_ = try await note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs) both need a backend to SEND them.

// Kotlin — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs/FCM) both need a backend to SEND them.

Ein Service Worker ist ein Hintergrundskript, das als Proxy zwischen App und Netz sitzt – es cacht die Shell und liefert sie offline aus; ein Web App Manifest sind JSON-Metadaten (Name, Icons, display: standalone, Start-URL), die die App installierbar machen; und HTTPS ist Pflicht, weil Service Worker außerhalb eines sicheren Kontexts den Dienst verweigern. Diese drei bilden die Vorderseite der App. Das save() in den Code-Tabs zeigt, was dahinter steckt: Der Cache ist ein Spiegel, und sobald das Netz zurück ist, synchronisiert sich der Schreibvorgang mit dem maßgeblichen Backend.

Wie eine PWA eine Seite offline ausliefert

Strategien für Offline-Caching

Entschieden wird pro Ressource, nicht pro App: Die App-Shell will Cache-first für sofortige Ladezeiten, die Live-Daten des Nutzers wollen Network-first für Aktualität, ein Feed verträgt Stale-while-revalidate, um sofort da zu sein und sich selbst zu korrigieren. Welche Strategie es auch wird – der Cache ist ein Lese-/Schreibpuffer über der API: Offline-Schreibvorgänge warten lokal und werden beim Wiederverbinden abgeglichen, dieselbe Aufhol-Disziplin, die jeder Offline-First-Client braucht.

Woher Push-Benachrichtigungen tatsächlich kommen

Der Mechanismus, den kaum ein Glossar erklärt, und der Grund, warum eine PWA schon zum Benachrichtigen ein Backend braucht. Der Client abonniert nur: Er bittet um Erlaubnis und erhält einen Subscription-Endpoint. Das Senden ist Serverarbeit – Ihr Backend → der Push-Dienst des Browsers → das push-Ereignis des Service Workers → eine angezeigte Benachrichtigung. Der Service Worker kann aufwachen und sie bei geschlossener App anzeigen, aber nichts kommt an, wenn kein Backend gesendet hat. “PWAs haben Push” ist ohne die Serverhälfte deshalb nur ein halbes Feature. Der Eintrag zu Push-Benachrichtigungen beschreibt die Zustellkette; hier zählt, dass Web Push und natives Push gleichermaßen in Ihrem Code enden, der sich fürs Senden entscheidet.

PWA vs. native App

Die ehrliche Asymmetrie steht in der letzten Zeile: Auf iOS sind PWAs am schwächsten – Installation nur über das Teilen-Menü, kein automatischer Install Prompt, Push erst nach der Installation und nur auf neueren Versionen, dazu lückenhafte Hintergrundsynchronisierung. Auf Android und Desktop ist der Abstand zu Native klein; auf iOS ist er für viele Produkte der ausschlaggebende Punkt.

Typische Anwendungsfälle

• Inhalte und Handel – Reichweite, SEO und geringe Installationshürde schlagen den Store-Download, wenn es darum geht, neue Nutzer zu erreichen.
• Interne Werkzeuge – installierbare, offlinetolerante Apps für bekannte Nutzer, ohne Verteilung über einen Store.
• Offline-First-Apps im Außendienst – Daten ohne Signal erfassen, synchronisieren, sobald es zurück ist; das Muster vom Cache als Puffer.
• Plattformübergreifende Reichweite mit kleinem Budget – eine Web-Codebasis deckt Plattformen ab, die ein nativer Build verdreifachen würde.
• Begleiter einer nativen App – dasselbe Backend bedient eine PWA für die Reichweite und eine native App für die Tiefe.

Sollten Sie eine PWA bauen? Entscheidungsmatrix

Grenzen und Trade-offs

• iOS deckelt das Erreichbare. Manuelle Installation über das Teilen-Menü, eingeschränktes Push und Lücken bei der Hintergrundsynchronisierung machen iOS zu der Randbedingung, die am häufigsten über PWA oder Native entscheidet.
• Der Hardware-Zugriff ist unvollständig. Bluetooth, NFC, Kontakte und fortgeschrittene Kamera-APIs sind je nach Betriebssystem begrenzt oder gar nicht verfügbar – gerätenahe Apps wollen weiterhin Native.
• Der Cache ist nicht die Datenbank. Wer den Service-Worker-Cache als Quelle der Wahrheit behandelt, lädt verlorene Schreibvorgänge und Konflikte mit veralteten Daten ein; er ist ein Puffer über dem maßgeblichen Backend.
• Push ist halb Client, halb Server. Das Abonnieren ist leicht; zum Senden braucht eine PWA weiterhin ein Backend – “offline und Push” ist damit ein Backend-Feature im Frontend-Gewand.
• Auffindbarkeit schneidet in beide Richtungen. Kein Store-Türsteher heißt auch kein Store-Schaufenster; Sie tauschen Kuratierung und Installationszeremonie gegen eine URL.

PWAs mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Sie ist die Backend-Hälfte jener Funktion, die die Frontend-Säulen nur zur Hälfte liefern: Der Service Worker cacht die Shell, aber Back4app ist die Quelle der Wahrheit, die dieser Cache spiegelt – authentifizierte Nutzer, synchronisierte Daten, die Offline-Schreibvorgänge beim Wiederverbinden abgleichen, und der Server, der tatsächlich sendet, was eine PWA nur abonnieren kann. Weil ein Backend über plattformspezifische SDKs eine PWA, eine klassische Web-App und eine native App gleichermaßen bedient, findet die plattformübergreifende Reichweite, die eine PWA im Frontend verspricht, ihr Gegenstück im einmal geschriebenen Backend – der Client cacht, die Plattform erinnert sich, und die beiden Hälften von “installierbar, offline und Push” finden endlich zusammen.