Was eine Progressive Web App wirklich ist
Eine Progressive Web App ist eine Website, die wie eine App funktioniert. Sie läuft im Browser, kann aber auf dem Homescreen installiert werden, offline arbeiten und Push-Benachrichtigungen empfangen. Die Kernmerkmale: HTTPS, Web App Manifest und Service Worker.
PWAs sind nicht im App Store oder Google Play. Nutzer greifen direkt über eine URL zu oder installieren sie über den Browser. Das klingt wie ein Nachteil, aber für bestimmte Anwendungsfälle ist es ein Vorteil: sofortige Updates ohne App-Store-Prüfung, keine 30 %-App-Store-Gebühr auf Zahlungen, einmaliger Codebase für alle Plattformen.
Beispiele für erfolgreiche PWAs: Twitter Lite (bis zu 75 % Dateneinsparung für Nutzer in Deutschland mit schlechter Verbindung), Starbucks (identische UX für iOS und Android mit einem Team) und viele Mittelstands-B2B-Tools, die intern distribiert werden.
Die Stärken von Progressive Web Apps
Kein App-Store-Overhead: Keine Prüfungszeiten (1-3 Tage für iOS), keine 30 %-Gebühren auf In-App-Käufe, keine Review-Ablehnungsrisiken. Für B2B-Software, die intern distribuiert wird, entfällt der gesamte App-Store-Management-Aufwand.
Einmal bauen, überall deployen: Dieselbe PWA läuft auf iOS, Android, Desktop und ChromeOS. Ein Entwickler, eine Codebasis, ein Deployment.
Sofortige Updates: Keine App-Store-Prüfung erforderlich. Eine kritische Bugfix-Deployment dauert Minuten, nicht Tage. Für SaaS-Produkte, die schnell iterieren, ist das ein erheblicher Vorteil.
Suchmaschinenoptimierung: PWA-Inhalte sind von Google indexierbar. Native App-Inhalte sind es nicht. Für Produkte, die organischen Traffic nutzen, ist das ein wesentlicher Unterschied.
Die Einschränkungen von Progressive Web Apps
PWAs haben reale Grenzen, die native Apps nicht haben:
iOS-Einschränkungen: Apple begrenzt PWA-Fähigkeiten auf iOS absichtlich. Push-Benachrichtigungen funktionieren erst ab iOS 16.4, Bluetooth und NFC sind nicht zugänglich, Kamerakontrolle ist eingeschränkt. Für Features, die diese Hardware nutzen, ist eine native App erforderlich.
Kein App-Store-Discovery: Über 50 % der App-Downloads kommen aus App-Store-Suchen. PWAs erhalten diesen Traffic nicht. Wenn dein Wachstumsmodell auf App-Store-Präsenz angewiesen ist, ist das ein erheblicher Nachteil.
Geringere Nutzererwartung: Für Consumer-Apps erwarten deutsche Nutzer eine App im App Store. "Gehe auf unsere Website und installiere sie im Browser" hat eine viel höhere Reibung als "Lade unsere App herunter".
Performance-Lücke: Für animationsintensive UIs oder Spiele ist native Performance immer noch merklich besser.
Wann native App wählen
Wähle eine native App (FlutterFlow oder nativ entwickelt), wenn:
- Du Hardware-Features brauchst: Bluetooth, NFC, erweiterte Kamera, Gyroscope - Du App-Store-Distribution für Consumer-Acquisition nutzt - Deine Nutzer die App auf dem Homescreen erwarten (für die meisten Consumer-Produkte) - Du Push-Benachrichtigungen auf iOS zuverlässig brauchst - Deine App offline-first ist mit komplexer Daten-Synchronisation
Für die meisten Consumer-Apps in Deutschland, Fintech, Health-Apps, Social, ist eine native App die richtige Wahl. Nutzer laden keine PWAs herunter; sie laden Apps herunter.
Wann PWA ausreichend ist
Eine PWA ist die richtige Wahl, wenn:
- Du ein internes Tool oder B2B-Software ohne App-Store-Distribution baust - Dein Produkt primär am Desktop genutzt wird mit gelegentlicher Mobile-Nutzung - Du keine In-App-Käufe hast (und die 30 %-Gebühr vermeiden willst) - Du extrem schnell iterieren musst ohne App-Store-Friction - Du nur ein Entwicklerteam für alle Plattformen hast
Ein gutes Beispiel aus dem deutschen Mittelstand: Produktionsmitarbeiter, die über Tablets auf ein internes Tool zugreifen, das aktuelle Fertigungsaufträge zeigt. Eine PWA deployt sich in Minuten auf alle Tablets, funktioniert auch bei schlechtem WLAN (Offline-Caching) und erfordert keine App-Store-Konten. Perfekter Anwendungsfall.
PWA-Installation und Offline-Modus: Wie es wirklich funktioniert
Wenn ein Nutzer auf Android eine PWA besucht, zeigt Chrome automatisch nach einigen Besuchen, die die Installationskriterien erfüllen, ein "Zum Startbildschirm hinzufügen"-Banner: ein gültiges manifest.json, ein registrierter Service Worker und HTTPS. Auf iOS muss der Nutzer manuell auf die Teilen-Schaltfläche tippen und "Zum Home-Bildschirm" auswählen, es wird kein Prompt angezeigt, was die Adoption auf Apple-Geräten deutlich reduziert.
Der Offline-Modus in einer PWA wird von einem Service Worker angetrieben, einer JavaScript-Datei, die Netzwerkanfragen abfängt und gecachte Antworten liefert, wenn das Netzwerk nicht verfügbar ist. Bei einer WeWeb-App bedeutet das, die App Shell (HTML, CSS, JS) zu cachen, damit die Oberfläche auch offline lädt. Dynamische Daten aus Supabase erfordern jedoch eine zusätzliche Caching-Strategie: Du musst API-Antworten in der Cache API oder IndexedDB speichern und dann veraltete Daten ausliefern, wenn die Netzwerkanfrage fehlschlägt.
Einen robusten Offline-Modus in einer WeWeb-PWA zu implementieren erfordert benutzerdefiniertes JavaScript. Die eingebaute PWA-Unterstützung von WeWeb cacht die App Shell, aber nicht deine Daten. Für Apps, bei denen Offline-Datenzugriff kritisch ist, Außendienst-Tools, Lagerbestands-Apps, die in Lagerhallen genutzt werden, ist eine native FlutterFlow-App mit Supabase-Offline-Sync die zuverlässigere Wahl.
Push-Benachrichtigungen: PWA vs. native
Push-Benachrichtigungen in einer nativen App sind der Goldstandard. FlutterFlow-Apps, die Firebase Cloud Messaging (FCM) verwenden, können Benachrichtigungen an iOS und Android senden, mit voller Unterstützung für Rich Notifications (Bilder, Action-Buttons, Deep Links), geplanter Zustellung und Hintergrund-Aufwecken. Die Zustellraten von Benachrichtigungen liegen bei nativen Apps konstant über 95 %.
PWA-Push-Benachrichtigungen verwenden die Web Push API. Auf Android unterstützen Chrome-PWAs Push-Benachrichtigungen, und sie funktionieren gut, vergleichbar mit nativen Apps bei der Zustellzuverlässigkeit. Auf iOS hat sich die Situation mit iOS 16.4 (veröffentlicht 2023) deutlich verbessert: Safari auf iOS unterstützt jetzt Web Push, aber nur für PWAs, die zum Home-Bildschirm hinzugefügt wurden. Web Push funktioniert nicht in Safari-Browser-Tabs auf iOS, sondern nur in installierten PWAs.
Für Produkte, bei denen die Zuverlässigkeit von Push-Benachrichtigungen geschäftskritisch ist, Zustellbenachrichtigungen, dringende Meldungen, zeitkritische Erinnerungen, ist nativ immer noch die sicherere Wahl. Für Produkte, bei denen Push ein Nice-to-have-Engagement-Tool ist, reicht die PWA-Web-Push-API aus, wenn du akzeptierst, dass iOS-Nutzer die PWA zuerst installieren müssen.
App-Store-Distribution vs. Web-Distribution
Der App Store und Google Play bieten einen Distributionsvorteil, den URLs nicht nachbilden können: Auffindbarkeit. Nutzer, die im App Store nach "Ausgaben-Tracker" oder "Team-Terminplanung" suchen, finden native Apps, keine Web-Apps. App Store Optimization (ASO) ist ein echter Wachstumskanal, viele Apps beziehen 40 bis 60 % ihrer neuen Installationen aus organischer App-Store-Suche.
Web-Distribution über eine URL hat eigene Vorteile. Du kannst den Link per E-Mail, Tweet oder QR-Code teilen. Nutzer können das Produkt ausprobieren, bevor sie irgendetwas installieren. Du kontrollierst den Update-Zyklus, ein Bugfix ist in Minuten live, nicht erst nach 24 bis 48 Stunden App-Store-Prüfung. Für B2B-Tools, die innerhalb von Organisationen geteilt werden, sind Web-Links oft einfacher zu verteilen, als jeden Mitarbeiter zur Installation einer App aufzufordern.
Die richtige Distributionsstrategie hängt von deinem Nutzerakquise-Modell ab. Wenn dein Wachstum über SEO, bezahlte Anzeigen oder Mundpropaganda über Links läuft, gewinnt eine über URL verteilte PWA möglicherweise schneller Nutzer. Wenn dein Wachstum von App-Store-Präsenz, Bewertungen und Kategorie-Rankings abhängt, brauchst du eine native App. Die meisten Produkte, die wir bei App Studio bauen, bedienen eine definierte Nutzerbasis, die vom Produktverantwortlichen eingeladen wird, in diesen Fällen ist Web-Distribution einfacher und effizienter.
Die Hybridlösung: WeWeb als PWA
WeWeb-Apps können als Progressive Web Apps konfiguriert werden. Das bedeutet: du baust einmal in WeWeb, hast eine voll funktionale Webanwendung und kannst optional eine installierbare PWA aktivieren.
Für Produkte, die beides brauchen, eine Web-App und eine leichte Mobile-Erfahrung, ist dies oft die effizienteste Lösung. Du bekommst: - Volle Web-App-Funktionalität auf Desktop - Installierbare Mobile-App-Erfahrung - Offline-Unterstützung über Service Worker - Keine App-Store-Gebühren
WeWeb hat eingebaute PWA-Unterstützung, die du in den Projekteinstellungen aktivierst. Einmal aktiviert, generiert WeWeb ein manifest.json mit deinem App-Namen, Icons, Theme-Farbe und Anzeigemodus (Standalone entfernt die Browser-Oberfläche, wodurch sich die installierte App vollständig nativ anfühlt). WeWeb registriert außerdem einen einfachen Service Worker, der die App Shell cacht.
Im WeWeb-Editor kannst du die Splash-Screen-Farben, das App-Icon in jeder benötigten Größe, die Ausrichtungssperre (Hochformat oder Querformat) und ob die App-Bar-Farbe zu deiner Marke passt, konfigurieren. Diese Einstellungen werden direkt auf die manifest.json-Eigenschaften abgebildet, die Browser bei der Installation der PWA verwenden.
Für die Daten-Caching-Ebene schreibst du benutzerdefiniertes JavaScript. Ein gängiges Muster ist, beim Laden der Seite eine WeWeb-JavaScript-Aktion hinzuzufügen, die navigator.onLine prüft, bei Online-Status frische Daten abruft und bei Offline-Status auf einen localStorage-Cache zurückgreift. Das gibt Nutzern einen aussagekräftigen Offline-Zustand statt eines leeren Fehlerbildschirms. Die meisten unserer Kunden-PWAs implementieren dieses Muster für ihre meistgenutzten Read-only-Screens.
Wenn du Hardware-Features oder App-Store-Distribution benötigst, füge FlutterFlow für die Mobile-Native-App hinzu und teile dasselbe Supabase-Backend. Das ist unser Standard-Empfehlungs-Setup für Mittelstands-B2B-Kunden in Deutschland.