Wohin steuert Flutter? Roadmap 2026 und wie man eine riesige App sicher umbaut

Zwei Talks, ein roter Faden

Auf der FlutterCon 2026 habe ich zwei Sessions gehört, die auf den ersten Blick nichts miteinander zu tun haben. Ein Panel mit dem Dart- und Flutter-Team zur Roadmap. Und ein Talk über ein Refactoring in einer Banking-App mit rund 100 Entwicklern.

Beim Nacharbeiten ist mir aufgefallen: Beide drehen sich um dieselbe Frage. Wie änderst du etwas Großes, ohne dass es kracht?

Das Flutter-Team macht das mit dem Framework selbst. Das Banking-Team mit einer produktiven App und einem riesigen Team im Rücken. Für mich als jemand, der Kunden-Apps baut und pflegt, ist beides relevant.

Was das Flutter-Team zur Richtung gesagt hat

Vorweg: Konkrete Ankündigungen gab es kaum. Zu Flutter 4 und möglichen Breaking Changes hieß es auf Nachfrage, dass es dazu nichts zu verkünden gibt. Auch zu HarmonyOS gab es nichts Konkretes. Das Team nimmt die Rückmeldung als Signal mit, mehr nicht.

Trotzdem steckt in dem Panel viel Richtung.

Material und Cupertino werden entkoppelt

Das war für mich der wichtigste Punkt. Material und Cupertino werden aus dem Flutter-Core herausgelöst. Auf die Frage, ob das nur Repo-Aufräumen sei, kam die Antwort: beides. Es ordnet die Repositories, und es verschiebt grundlegende Bausteine in den Core.

Das Ziel ist, dass Design-System-Updates schneller kommen, ohne auf den nächsten Framework-Release zu warten. Komplexe gemeinsame Logik wie die Texteingabe wandert in die Basis-Widgets, damit neue Design-Systeme sie wiederverwenden können, statt sie nachzubauen.

Mein Take: Das ist ein echter Gewinn für Projekte mit eigenem Design. Wenn du eine App hast, die nicht wie Material aussehen soll, baust du künftig auf sauberen, unopinionated Grundlagen auf. Das passt zu dem, was ich in Kundenprojekten ohnehin mache: ein eigenes Design-System obendrauf, nicht gegen das Framework kämpfen.

Analyzer und Mono-Repos werden schneller

Für große Codebasen gab es zwei konkrete Dinge. Pub Workspaces vereinheitlichen Dependency-Versionen in einem Mono-Repo und verhindern, dass dieselben Pakete mehrfach geladen werden. Das senkt den Speicherverbrauch des Analyzers deutlich. Dazu kommt natives Hashing für die inkrementelle Analyse, das laut Panel grob 8 Prozent Wall-Clock-Zeit bringt, je nach Projekt.

Wichtig, weil es im Q&A kam: Das ist eine Verbesserung des Analyzers im SDK. Mit dem Build-Modus deiner App (Debug, Profile, Release) hat das nichts zu tun.

Und: Performance-Probleme sind oft projektspezifisch. Das Team bat ausdrücklich um detaillierte Issue-Reports mit reproduzierbarem Kontext.

KI-Agenten und Dart

Dart profitiert hier von alten Entscheidungen. Das CLI-first-Tooling und das starke Typsystem machen es Agenten leichter, weil die Rückmeldungen des Compilers klar sind. Gute Dokumentation und gute Compiler-Meldungen helfen Agenten, besseren Code zu schreiben. Das deckt sich mit meiner Erfahrung. Ich schreibe mehr dazu in meinem Artikel über KI in der App-Entwicklung.

Zur Zukunft von Apps sagte ein Panelist: Apps verschwinden nicht, weil Nutzer Konsistenz und Vertrauen brauchen, gerade bei Finanzen und Gesundheit. Wahrscheinlicher sind Hybride: eine verlässliche UI plus Schnittstellen, über die KI-Agenten kleine Aufgaben erledigen. Das ist ein Ausblick, keine Roadmap-Zusage.

Was sonst noch hängen geblieben ist

• Flutter soll über Mobile hinaus wachsen: Web, Desktop, Automotive, Kiosks, Embedded.
• Dart-Dataclasses sind weiter in Diskussion. Primary Constructors sind ein Schritt, aber was genau Equality, Immutability und copyWith leisten sollen, ist offen.
• Eine Haltung, die ich gut finde: keine Halblösungen. Lieber länger an der tieferen Ursache arbeiten, auch wenn kleine Probleme dadurch warten müssen.
• Auf die Frage nach der größten Bedrohung für Flutter kam keine Konkurrenz als Antwort, sondern: irrelevant werden und Trends verpassen.

Was das für deine Projekte heißt

Ich glaube, die Richtung ist gut für Kundenprojekte. Nichts davon zwingt dich zu einem Umbau. Aber es verändert, wie ich plane.

Eigenes Design wird einfacher. Wer Wert auf Marke legt, profitiert von der Entkopplung. Mehr zu meiner Sicht auf das Framework findest du in Warum ich Flutter liebe.

Tooling wird für große Apps besser. Wenn deine App wächst, merkst du das zuerst am Analyzer und an den Build-Zeiten. Hier tut sich was.

Keine Panik wegen fehlender Ankündigungen. Wer sich fragt, ob Flutter noch sicher ist: Ich hab das schon in Flutter ist tot, warum das Quatsch ist aufgeschrieben. Das Panel hat mir eher bestätigt, dass das Team Wert auf solide Grundlagen legt. Und es gilt weiter: Google unterstützt überlappende Technologien wie Flutter und Kotlin Multiplatform und lässt Nutzer entscheiden. Wenn du vergleichen willst, hilft dir Flutter vs React Native.

Der Praxisfall: Eine Banking-App mit 100 Entwicklern

Jetzt zum zweiten Talk. Agnieszka Forajter und Kamil Sztandur von LeanCode haben gezeigt, wie sie eine Flutter-Banking-App refactort haben. Titel: "Flutter Refactors at Scale: Change Everything, Break Nothing".

Die Ausgangslage klingt für viele Agenturen vertraut, nur eine Nummer größer:

• Rund 100 Mobile-Entwickler, aufgeteilt in Squads.
• Ein Poly-Repo mit etwa 50 Paketen, zum Beispiel Payments, Core und Design System.
• Eine Änderung in einem Repo kann das Hauptprojekt kaputt machen und alle blockieren.
• Die Codequalität war eher mäßig, auch weil viele Entwickler aus dem Native-Bereich kamen und Dart und Flutter-Architektur noch lernten.
• Das Design System wurde nicht konsequent genutzt. Viele griffen zu Standard-Widgets.

Die Regeln waren hart. Feature-Lieferung geht vor. Nichts, was schon läuft, darf kaputtgehen. Und der Nutzen muss klar sein.

Die Strategie in Phasen

Das Team hat nicht einfach losgelegt, sondern in Phasen gearbeitet:

1. Neuen schlechten Code verhindern. Erst bremsen, dann aufräumen.
2. Altbestand automatisiert bereinigen, in vielen kleinen PRs statt einem Monster.
3. Eine Qualitätskultur aufbauen, die sich selbst trägt.
4. Code-Ownership klären, bewusst erst später, nachdem der Nutzen sichtbar war.

Das gefällt mir, weil die Reihenfolge stimmt. Es bringt nichts, ein Jahr lang aufzuräumen, während nebenan neuer Müll entsteht.

Phase 1: Eigene Lint-Regeln

Mit dem analyzer_plugin hat das Team eigene Lint-Regeln samt Quick Fixes gebaut. Ein einfaches Beispiel aus dem Talk: Jede Cubit-Klasse muss auf Cubit enden. Das ist banal, spart aber Diskussionen im Review. Die Regeln erzwingen Team-Konventionen und Architektur, fangen Fehler vor dem Review ab und lehren nebenbei Best Practices. Auch KI-Agenten halten sich dadurch eher an die Regeln.

LeanCode hat viele dieser Regeln als Open-Source-Paket leancode_lint auf pub.dev veröffentlicht.

Das Team berichtete danach von gleichmäßigerem Code, weniger Bugs in neuem Code, höherer gefühlter Geschwindigkeit und weniger negativen PR-Kommentaren.

Phase 2: Codemod statt Handarbeit

Für den Altbestand kam codemod zum Einsatz, eine Art intelligentes Suchen und Ersetzen auf Basis des Syntaxbaums. Ein Suggestor erzeugt Patches, die man im CLI annimmt oder ablehnt. Beispiel aus dem Talk: ElevatedButton durch einen eigenen AppButton ersetzen, inklusive Mapping der Argumente.

Weitere Einsatzfälle: hartkodierte Farben ersetzen, Navigationsumstellungen von Navigator auf einen Router, Deprecations einfügen, fehlende Semantic Labels ergänzen. Die Suggestoren lagen in einem eigenen Paket, das alle Repos einbinden. So lief eine Änderung über rund 50 Repos mit einem Befehl.

KI und Codemod zusammen

Hier wurde es für mich spannend. KI versteht Absicht und Kontext, ist aber nicht deterministisch. Gleiche Eingabe, andere Ausgabe. Dazu kommen Kosten und Datenschutz.

Der Ansatz der Speaker: KI als Architekt, Codemod als Ausführer. Die KI hilft, die Strategie zu entwerfen und die Suggestoren zu schreiben. Die Masse an Änderungen läuft dann deterministisch und schnell durch Codemod. Mein Fazit dazu: Lass die KI das Werkzeug bauen, nicht tausend Dateien einzeln anfassen.

Das Sicherheitsnetz

Die Speaker nannten sechs Schichten:

1. CI/CD-Prüfungen bei jedem PR. Falls du das Konzept auffrischen willst: Was ist CI/CD.
2. Testabdeckung für kritische Flows.
3. Golden Tests, vor allem bei Design-System-Änderungen.
4. Manuelle Regressionstests durch QA.
5. Review durch Maintainer und Tech Leads mit Domänenwissen.
6. Peer Review durch Leute, die sich mit Refactoring und Linting auskennen.

Zusätzlich erwähnten sie Maestro, mit dem Entwickler oder KI-Agenten eine laufende App bedienen und per Screenshot gegen eine Baseline prüfen können.

Und ein Satz blieb hängen: Vertrau nichts blind, auch wenn der PM die Zeit fürs Refactoring freigegeben hat.

Was ich daraus für meine Arbeit ableite

Ich arbeite nicht mit 100 Leuten. Trotzdem lässt sich das runterbrechen. Das ist meine Einschätzung, nicht die der Speaker:

• Erst bremsen, dann aufräumen. Auch in einem kleinen Projekt lohnt sich ein strenges analysis_options.yaml, bevor ich alten Code anfasse.
• Kleine PRs. Ein großer Umbau in kleinen Schritten ist reviewbar und rückholbar.
• Deterministisch vor magisch. Wenn ich etwas hundertfach ändern muss, schreibe ich ein Skript oder einen Codemod. Die KI hilft beim Bauen, nicht beim Durchklicken.
• Tests vor dem Umbau. Ohne Netz kein Refactoring. Das war schon Thema in meinem Artikel über Solo-Entwickler: Testing ist der Engpass.

Für Kunden heißt das: Eine gewachsene App ist kein Totalschaden. Mit der richtigen Reihenfolge lässt sie sich Stück für Stück verbessern, ohne dass der Betrieb steht. Wenn du über eine neue App nachdenkst, schau auch in App entwickeln lassen.

Fazit

Das Flutter-Team liefert keine großen Überraschungen, aber eine klare Linie: sauberere Schichten, schnelleres Tooling, mehr Offenheit für Agenten und andere Bildschirme. Die Entkopplung von Material und Cupertino ist für mich das wichtigste Signal.

Und der Banking-Fall zeigt, wie man mit dieser Art von Veränderung im Alltag umgeht: in Phasen, automatisiert, mit Netz und Menschen, die den Code kennen. Das gilt für 100 Entwickler genauso wie für ein Team von einer Person.

Häufig gestellte Fragen (FAQ)

Dieser Artikel wurde inspiriert vom Interview-Panel zur Dart- und Flutter-Roadmap und dem Talk "Flutter Refactors at Scale" von Agnieszka Forajter und Kamil Sztandur (LeanCode) auf der FlutterCon 2026.