Warum PWA nicht tot ist: eine Fallstudie zu trefa.app

Zwischen 2017 und 2020 war PWA ein technologischer Hype-Cycle. Konferenzen, Blog­posts, offizielle Unterstützung von Google und Microsoft. Dann kam die Ernüchterung — iOS hielt zentrale APIs verschlossen, Install-Prompts erwiesen sich als verwirrend, das Marketing nativer Apps war immer noch stärker. Die Community zog weiter zu Flutter, React Native und Capacitor.

Leise passierte aber noch etwas. Die PWA-Technologie reifte weiter. Apple hat in den letzten Jahren die fehlenden APIs ergänzt, Browser haben den Install-Flow verbessert, die Service-Worker-Spec hat sich gefestigt. Und für Produkt­teams ohne großes Budget ist PWA zu einer überraschend starken Option geworden.

Dieser Artikel ist eine ehrliche Fallstudie zu trefa.app — eine Firmen-Tippspiel-App, gebaut als PWA — nach einem Jahr in Produktion. Was funktioniert hat, was nicht und wem ich PWA heute empfehlen würde.

Kontext: Was ist trefa.app

Trefa.app ist eine Web-App für Firmen-Tippspiele. Der Nutzer meldet sich mit Google an, legt eine Liga für seine Firma an, lädt Kolleginnen und Kollegen per Link oder QR-Code ein, und gemeinsam tippen sie die Ergebnisse der Spiele. Die App synchronisiert Daten von Sport-APIs (NHL, Premier League, Welt­meisterschaften) und berechnet die Punkte in Echtzeit neu.

Das Frontend ist Next.js 16 + React 19 + Tailwind, gehostet bei Vercel. Das Backend ist Django 5 + DRF + Channels auf Hetzner. Dazwischen PostgreSQL auf Supabase und Redis für Echtzeit­kommunikation.

Ein schönes Detail: Es gibt keine native iOS- oder Android-App. Die PWA ist der einzige Client. Nutzer auf iPhone, Android, Windows und macOS verwenden exakt dasselbe.

Warum wir PWA statt nativ gewählt haben

Die Entscheidung war weitgehend ökonomisch. Eine native App hätte bedeutet:

• Entwicklung zweier paralleler Clients (iOS Swift + Android Kotlin) oder ein Cross-Platform-Framework (Flutter, React Native).
• App Store + Google Play Submission-Prozess — Submission-Gebühren, Review-Verzögerungen, periodisches Re-Publishing bei Änderungen an der Backend-API.
• Push-Benachrichtigungen über APNs und FCM, zwei verschiedene Infra­strukturen, zwei verschiedene Zertifizierungs­prozesse.
• Update-Flow über die Stores — der Nutzer muss aktiv aktualisieren, ein Teil bleibt monatelang auf einer älteren Version.

Für ein Produkt mit relativ kleiner Zielgruppe (Firmen­teams, kein Massen­markt) waren die Kosten der nativen Entwicklung deutlich höher als der Nutzen. PWA hat all die oben genannten Punkte auf einmal beseitigt.

Technische Vorteile, die Nutzer nie bemerken

Diesen Teil hätte ich vor dem Produktions­start unterschätzt. Aus Entwicklungs­sicht bringt PWA eine Reihe konkreter Vorteile, die jährlich Wochen Arbeit sparen:

Deploy ist sofort. Push nach main → Vercel baut → in 2 Minuten ist die neue Version bei allen Nutzern. Keine Submission, kein Warten, kein Jonglieren von Kompatibilität zwischen Client- und Backend-Versionen. Mache ich eine Breaking-API-Änderung, ship ich am nächsten Tag den Fix und alle haben ihn sofort.

Eine Codebase für alles. iOS, Android, Windows, macOS, Linux — überall dieselbe App. Keine plattform­spezifischen Bugs („das bricht nur auf dem iPhone 13 im Dark Mode"), keine duplizierte Implementierung.

Kurzer Weg zum Nutzer. Link verschicken, klicken, in der App. Kein „lade unsere App im App Store, registriere dich und melde dich dann an". Für B2B-Produkte mit niedriger Nutzungs­frequenz (ein Tippspiel läuft nur während eines Sport­turniers) ist das ein riesiger Konversions­vorteil.

Push-Benachrichtigungen funktionieren auch ohne Installation. Der Service Worker registriert das Push-Subscription. Klickt der Nutzer „Benachrichtigungen erlauben", bekommt er Hinweise vor den Spielen, egal ob er die App auf den Homescreen gelegt hat oder sie nur gelegentlich in Safari öffnet.

Was PWA nicht kann (ehrlicher Abschnitt)

Hier ist Ehrlichkeit wichtiger als Marketing. PWA hat reale Grenzen, an die wir in Produktion gestoßen sind.

iOS-Push-Benachrichtigungen haben Eigenheiten. Apple Web Push existiert seit iOS 16.4, funktioniert aber nur, wenn der Nutzer die PWA auf den Homescreen gelegt hat. Nutzt er die App über Safari-Tabs, bleibt das Push-Subscription nicht erhalten. Diese Friction hat eine native App nicht.

App-Store-Präsenz fehlt. Für manche Käufer­personas (HR-Abteilungen, Enterprise-IT-Manager) bedeutet „nicht im App Store" gleich „nicht seriös". Subjektiv, aber real.

Manche OS-APIs sind nicht verfügbar. Bluetooth Low Energy, NFC, vollständiger Datei­system-Zugriff — für eine typische App egal, aber wer diese Features braucht, dem setzt PWA Grenzen.

Offline-Modus ist möglich, aber nicht automatisch. Der Service Worker muss manuell aufgesetzt, Cache-Strategien entworfen, Sync-Queues implementiert werden. Für eine vollständig offline-first App ist das mehr Arbeit, als Entwickler erwarten.

Performance-Benchmark vs. nativ: PWA ist beim ersten Laden um ~15–25 % langsamer (JS-Bundle-Parsing) und ~5–10 % im Alltag. Für die meisten Apps nicht spürbar, für Hardcore-Gaming oder Videobearbeitung ein Deal­breaker.

Ergebnisse nach einem Jahr in Produktion

Konkrete Daten von trefa.app nach einem Jahr Betrieb:

• Plattform­übergreifende Stabilität — ein Entwicklungs­team von einer Person pflegt die App auf allen Betriebs­systemen ohne plattform­spezifische Bugs. Gleicher Test­zyklus für alle.
• Deploy-Frequenz — im Schnitt 3–5 Deploys pro Woche über Vercel. Keiner davon kümmert sich um App-Store-Submission-Delays.
• Push-Benachrichtigungen — ~70 % der Nutzer aktiv, Push-Delivery-Rate ~95 % auf Android, ~85 % auf iOS (wegen des Homescreen-Install-Erfordernisses).
• Keine App-Store-Gebühren — gespart rund 70 USD jährlich an Developer-Accounts plus rund 30 % Provision auf Transaktionen (die sonst bei In-App-Purchase fällig würden).

Der Haupt-Business-Vorteil war am Ende aber nicht technisch. Es war die Iterations­geschwindigkeit. Schrieb ein Kunde „diese Funktion würde mir helfen", begann ich meist am selben Tag und in der Woche darauf war sie live. Mit einer nativen App geht das schlicht nicht.

Wem ich PWA heute empfehlen würde

PWA passt, wenn mindestens zwei der folgenden Punkte zutreffen:

• Du hast begrenzte Ressourcen und kannst dir keine zwei nativen Apps plus eine Web-Version leisten.
• Deine Nutzer benutzen die App gelegentlich (nicht täglich), sodass niedrige Friction beim ersten Öffnen wichtig ist.
• Deine App braucht keine Hardcore-OS-APIs (Bluetooth, NFC, vollständiges Datei­system).
• Du willst ohne App-Stores deployen.
• Deine Zielgruppe ist gemischt — iOS plus Android, Mobile plus Desktop.

PWA ist vermutlich nicht die richtige Wahl, wenn:

• Deine App täglich, mehrere Stunden am Tag läuft, und die Nutzer sie intensiv verwenden (soziale Netzwerke, Messaging).
• Du fortgeschrittene OS-Integrationen brauchst.
• Deine Käufer eine App-Store-Präsenz erwarten.
• Performance kritisch ist (Gaming, Video, AR).

Fazit

Der PWA-Hype mag vorbei sein, doch die Technologie ist still an den Punkt herangewachsen, an dem sie für viele Produkte die bessere Wahl ist als die native Entwicklung. Trefa.app steht seit einem Jahr auf PWA und ich sehe keinen Grund, das zu ändern. Im Gegenteil — würde ich heute nochmal anfangen, würde ich schneller einsteigen.

Wenn du für dein Projekt zwischen PWA und einer nativen App abwägst, berücksichtige eines jenseits der technischen Argumente: PWA bringt dich schneller in Produktion. Und in der frühen Phase ist Iterations­geschwindigkeit wertvoller als alles andere.

Übrigens, du kannst trefa.app selbst ausprobieren — keine Installation, nur ein Klick und du tippst.