Wann lohnt sich der Native-Shell-Ansatz – und wann nicht?

Der Ansatz lohnt sich, wenn bereits ein gepflegtes Web-Frontend existiert und dessen Logik nicht ein zweites Mal nativ nachgebaut werden soll, die App aber trotzdem in die App-Stores und an native Funktionen wie Push, Scanner oder biometrische Sperre kommen muss. Weniger sinnvoll ist er, wenn die App durchgehend hardwarenah oder hochgradig interaktiv sein muss – dann spielt eine voll native bzw. voll in Flutter umgesetzte Oberfläche ihre Stärken aus. Faustregel: Je mehr Wert in der bestehenden Web-Codebasis steckt und je klarer der native Bedarf abgrenzbar ist, desto eher trägt der Shell-Ansatz.

Wie sicher ist die typsichere Bridge gegen eingeschleusten JavaScript-Code?

Jede Nachricht aus der WebView wird vor der Verarbeitung gegen den konfigurierten PWA-Host geprüft – Aufrufe aus einer fremden Herkunft erreichen die nativen Handler nicht. Zusätzlich validiert die Bridge jede Nachricht gegen ein Zod-Schema, das als gemeinsamer Vertrag dient; was nicht der Spezifikation entspricht, wird verworfen, statt ungeprüft an nativen Code zu gelangen. So bleibt die native Funktionalität gekapselt, auch wenn im Web-Layer unerwarteter Code landet.

PWA in nativer Shell vs. komplette Neuentwicklung – wann was?

Eine native Shell ist der schnellere und günstigere Weg, wenn ein funktionierendes Web-Frontend existiert und zentral gepflegt werden soll: Eine Änderung im Web wirkt sofort in App und Browser, ohne doppelte Implementierung. Eine komplette Neuentwicklung lohnt sich, wenn die bestehende Codebasis am Ende ihres Lebenszyklus ist, die App-Erfahrung sich deutlich vom Web unterscheiden soll oder durchgängig native Performance gefragt ist. In diesem Projekt war die PWA aktuell und sollte parallel weiterlaufen – deshalb fiel die Wahl auf die Shell.

Wie funktioniert Mehrmandantenfähigkeit aus einer einzigen Codebasis?

Über ein Flavor-System auf Basis von flutter_flavorizr entstehen aus demselben Quellcode separate Build-Varianten je Marke und Umgebung – jede mit eigener Firebase-Konfiguration, eigenen Signing-Credentials und eigenem Store-Eintrag. In diesem Projekt sind das 21 Varianten, die GitHub Actions und Fastlane automatisiert bauen, signieren und ausliefern. Neue Mandanten kommen so über Konfiguration hinzu, statt über einen eigenen Code-Zweig pro Kunde.

Wie lässt sich der Aufwand für ein solches Projekt einschätzen?

Der Aufwand hängt vor allem an der Zahl der nativen Funktionen, der Menge an Mandanten und Build-Varianten sowie den Sicherheits- und Compliance-Anforderungen. Eine erste Größenordnung lässt sich unverbindlich mit dem App-Kosten-Rechner ermitteln; für ein belastbares Angebot schauen wir den konkreten Scope gemeinsam an.

Übergeben (Weiterentwicklung beratend begleitet)

Stack: Flutter, Bloc, flutter_inappwebview, Freezed, Zod, Fastlane, GitHub Actions

Native Shell für eine PWA: Flutter-App mit typsicherer Bridge

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.

Veröffentlicht am 23. Juni 2026Aktualisiert am 3. Juli 2026

Illustration einer Brücke, die eine PWA-Oberfläche und eine Mobile-App verbindet – mit Engineer-Figuren an beiden Plattformen

Problem

Das Problem

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.

Eine bestehende PWA, native Funktionen, mehrere Mandanten – aus einer Codebasis.

Vorgehen

Mein Vorgehen

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

Eine bestehende Next.js-PWA als native App in den Stores – 21 Build-Varianten aus einer Codebasis

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

Vorab geklärt

Häufige Fragen

Lassen Sie uns über Ihr App-Projekt sprechen

Migration, MVP oder Weiterentwicklung: Schreiben Sie mir oder buchen Sie direkt ein Erstgespräch.

E-Mail schreiben Erstgespräch buchen