Native Shell für eine PWA: Flutter-App mit typsicherer Bridge
Übergeben (Weiterentwicklung beratend begleitet)
Mandantenfähige Flutter-App, die eine bestehende Next.js-PWA in einer nativen Shell einbettet, mit typsicherer Bridge, nativen Funktionen und CI/CD für 21 Build-Varianten aus einer Codebasis.
Das Problem
Eine bestehende PWA, native Funktionen, mehrere Mandanten, alles aus einer Codebasis.
Ein etablierter Anbieter in einem stark regulierten Umfeld mit hohen Anforderungen an IT-Sicherheit, Datenschutz und Verfügbarkeit wollte seinen Nutzern mehr bieten als eine mobile Website. Das bestehende Next.js-Web-Frontend sollte als App in den Stores erscheinen und um native Funktionen wie Push-Benachrichtigungen, einen Barcode-Scanner für physische Belege und eine biometrische Sperre ergänzt werden. Gefragt war keine Neuentwicklung, sondern eine Erweiterung, bei der die Frontend-Logik nicht doppelt gepflegt werden musste.
Zwei Randbedingungen prägten das Projekt. Die PWA und die native App mussten parallel entstehen und unabhängig voneinander vorankommen, ohne sich gegenseitig zu blockieren. Zudem sollte die App von Anfang an mehrere Marken und Umgebungen aus einer einzigen Codebasis bedienen, statt pro Mandant einen eigenen Zweig zu pflegen.
Mein Vorgehen
- Plattformen
- iOS, Android
Eine mandantenfähige Flutter-App, die die PWA in einer nativen Shell einbettet und über eine typsichere Bridge mit ihr kommuniziert. Ich habe das Projekt als alleiniger Flutter-Entwickler im Auftrag einer Digitalagentur umgesetzt, die die PWA-Entwicklung und die Kundenkoordination verantwortete. Damit beide Seiten unabhängig arbeiten konnten, lag der Bridge-Vertrag als Zod-Schema vor und diente als Single Source of Truth, gegen die sowohl die App als auch das Frontend dieselbe Spezifikation validieren konnten.
Den Kern bildet eine modulare Bridge nach dem Handler-Registry-Pattern: Jeder native Funktionsbereich ist in einem eigenen Bridge-Handler mit einheitlicher Schnittstelle implementiert. Ein Dispatcher leitet eingehende Nachrichten anhand ihres Typs weiter. Jede Nachricht wird gegen den konfigurierten PWA-Host geprüft, sodass eingeschleuster JavaScript-Code keine nativen Handler aufrufen kann. Die Kommunikation läuft in beide Richtungen: Die App schickt ebenfalls typsichere Events an die WebView, beispielsweise bei einem FCM-Token-Refresh oder einem Theme-Wechsel. Ein Flavor-System auf Basis von flutter_flavorizr erzeugt die Varianten je Mandant und Umgebung, jede mit eigener Firebase-Konfiguration, eigenen Signing-Credentials und Store-Listings. GitHub Actions und Fastlane bauen, signieren und verteilen jede Variante automatisiert an TestFlight und die Play Console.
Ergebnis
Die App integriert die bestehende PWA als native Shell und ergänzt sie um Funktionen, die im Browser nicht oder nur eingeschränkt verfügbar sind. Dazu gehören Push-Benachrichtigungen über FCM, ein Barcode-Scanner zur Verknüpfung physischer Belege mit dem Nutzerkonto, Geolokalisierung, Deep Links, Dark-Mode-Sync, Home-Screen-Widgets und eine biometrische Sperre. Aus einer einzigen Codebasis entstehen 21 Build-Varianten für mehrere Marken auf iOS und Android, vollständig automatisiert von Build bis Store-Auslieferung. Dank typsicherem Vertrag und modularem Handler-Pattern kann das Team neue native Funktionen mit wenig Aufwand ergänzen. Die wiederverwendbare PWA-seitige Bridge erlaubt es dem Frontend-Team außerdem, unabhängig gegen eine klar dokumentierte API zu arbeiten. Das Projekt wurde übergeben; die weitere Entwicklung und Wartung liegt beim Auftraggeber, den ich dabei weiterhin beratend unterstütze.
Weitere Eindrücke
Ähnliche Ausgangslage? Dann sprechen wir darüber.
Häufige Fragen
Leistungen hinter dem Projekt
Lassen Sie uns über Ihr App-Projekt sprechen.
Migration, MVP oder Weiterentwicklung: Schreiben Sie mir oder buchen Sie direkt ein Erstgespräch.