FlutterFlow nach Flutter migrieren: vom Export zur wartbaren Codebasis

FlutterFlow ist schnell, solange eine App in den Baukasten passt. Irgendwann kommen Anforderungen, die sich dort nur mit viel eigenem Code oder gar nicht umsetzen lassen: eine eigene Architektur, Tests, Code-Reviews im Team, komplexe Zustände, besondere native Integrationen. Dann stellt sich die Frage, die App als normales Flutter-Projekt weiterzuführen.

Was der Export mitbringt

FlutterFlow erzeugt echten Flutter-Code. Je nach Plan lässt er sich herunterladen oder in ein GitHub-Repository übertragen. Ein Export enthält typischerweise:

• pro Seite ein Widget und eine zugehörige Model-Klasse,
• den Ordner flutter_flow/ mit Theme, Hilfsfunktionen und Standard-Widgets,
• einen globalen App-Zustand (FFAppState) auf Basis von Provider,
• das Routing auf Basis von go_router,
• die Anbindung an das Backend, etwa Firebase, Supabase oder REST-APIs,
• eigenen Code aus FlutterFlow unter custom_code/.

Der Code läuft, ist aber für den Editor geschrieben, nicht für Menschen: viel generierter Boilerplate, Logik in Widgets, Zustand an vielen Stellen.

Die wichtigste Entscheidung vorab

Der Schritt ist praktisch eine Einbahnstraße. Änderungen am exportierten Code lassen sich nicht in den FlutterFlow-Editor zurückführen. Arbeitet das Team nach dem Export in beiden Welten weiter, überschreibt der nächste Export die Handarbeit. Deshalb braucht es einen Stichtag, ab dem nur noch im Code entwickelt wird.

Reihenfolge der Migration

1. Einfrieren und exportieren. Der letzte Stand aus FlutterFlow wird ein eigener Commit mit Tag im Repository.
2. Eine Build-Basis schaffen. Flutter- und Paketversionen festhalten, flutter analyze sauber bekommen, CI einrichten, etwa mit GitHub Actions oder Codemagic, und die Builds für iOS und Android reproduzierbar machen.
3. Kritische Abläufe absichern. Vor dem Umbau Tests für Anmeldung, Kernfunktionen und Bezahlprozesse schreiben, damit Refactorings nichts unbemerkt brechen.
4. Schrittweise umbauen, nicht neu schreiben. Zuerst Theme und Design-Tokens, dann den globalen Zustand, etwa nach Riverpod, dann Datenzugriff und API-Schicht, zuletzt die Seiten. Nach jedem Schritt bleibt die App releasefähig.
5. Routen stabil halten. Deep Links und Push-Benachrichtigungen hängen an den Pfaden. Änderungen daran gehören geplant.
6. Generierten Ballast entfernen. Ungenutzte Seiten, Hilfsfunktionen und Pakete löschen. Das verkleinert die App und macht den Code überschaubar.

Ein kompletter Neubau ist selten nötig. Er lohnt sich eher, wenn die fachliche Struktur der App nicht mehr passt, nicht nur ihr Code.

Unterstützung

Ich überführe FlutterFlow-Projekte in sauberen Flutter-Code und bringe sie in die Stores. Bevor wir über Umfang und Aufwand sprechen, sehe ich mir Export, Build-Pipeline und Store-Konten an. Kontakt aufnehmen.