Where is Flutter heading? The 2026 roadmap and how to safely rebuild a huge app

Two talks, one common thread

At FlutterCon 2026 I sat through two sessions that look unrelated at first. A panel with the Dart and Flutter team about the roadmap. And a talk about a refactoring in a banking app with around 100 developers.

When I went back through my notes, I noticed they're about the same question. How do you change something big without breaking it?

The Flutter team does it with the framework itself. The banking team does it with a live app and a huge team behind it. As someone who builds and maintains client apps, both matter to me.

What the Flutter team said about direction

First, the honest part: there were hardly any concrete announcements. Asked about Flutter 4 and possible breaking changes, the answer was that there's nothing to announce. Same for HarmonyOS. The team takes the feedback as a signal, nothing more.

Still, the panel had plenty of direction in it.

Material and Cupertino are being decoupled

For me this was the biggest point. Material and Cupertino are being pulled out of Flutter core. When someone asked whether that's just repo cleanup, the answer was: both. It organizes the repositories, and it moves foundational building blocks into the core.

The goal is that design system updates ship faster, without waiting for the next framework release. Complex shared logic like text input moves into the base widgets, so new design systems can reuse it instead of rebuilding it.

My take: this is a real win for projects with their own design. If your app shouldn't look like Material, you'll build on clean, unopinionated foundations. That matches what I already do in client projects: put a custom design system on top instead of fighting the framework.

Analyzer and mono-repos get faster

Two concrete things for large codebases. Pub workspaces unify dependency versions in a mono-repo and stop the same packages from being loaded multiple times. That cuts analyzer memory use a lot. On top of that, native hashing for incremental analysis, which the panel put at roughly 8 percent wall-clock time, depending on the project.

Worth knowing, since it came up in Q&A: this is an improvement to the analyzer in the SDK. It has nothing to do with your app's build mode (debug, profile, release).

Also: performance problems are often project-specific. The team explicitly asked for detailed issue reports with reproducible context.

AI agents and Dart

Dart benefits from old decisions here. The CLI-first tooling and the strong type system make life easier for agents because the compiler feedback is clear. Good documentation and good compiler messages help agents write better code. That matches my experience. I wrote more about it in my post on AI in app development.

On the future of apps, one panelist said apps aren't going away because users need consistency and trust, especially in finance and health. More likely are hybrids: a reliable UI plus interfaces that let AI agents handle small tasks. That's an outlook, not a roadmap commitment.

What else stuck with me

• Flutter should grow beyond mobile: web, desktop, automotive, kiosks, embedded.
• Dart data classes are still under discussion. Primary constructors are a step, but what exactly equality, immutability and copyWith should do is open.
• An attitude I like: no half solutions. Better to work on the deeper cause longer, even if small problems have to wait.
• Asked about the biggest threat to Flutter, nobody named a competitor. The answer was becoming irrelevant and missing trends.

What this means for your projects

I think the direction is good for client work. None of it forces a rebuild. But it changes how I plan.

Custom design gets easier. If your brand matters, the decoupling helps. More on how I see the framework in Why I love Flutter.

Tooling gets better for big apps. When your app grows, you notice it first in the analyzer and build times. Things are moving there.

No panic over missing announcements. If you wonder whether Flutter is still a safe bet, I wrote about that in Flutter is dead, why that's nonsense. The panel mostly confirmed to me that the team cares about solid foundations. And Google keeps supporting overlapping technologies like Flutter and Kotlin Multiplatform and lets users choose. If you want to compare, Flutter vs React Native helps.

The real-world case: a banking app with 100 developers

Now the second talk. Agnieszka Forajter and Kamil Sztandur from LeanCode showed how they refactored a Flutter banking app. Title: "Flutter Refactors at Scale: Change Everything, Break Nothing".

The starting point will sound familiar to many agencies, just one size bigger:

• Around 100 mobile developers, split into squads.
• A poly-repo with about 50 packages, for example payments, core and design system.
• A change in one repo can break the main project and block everyone.
• Code quality was mediocre, partly because many developers came from native and were still learning Dart and Flutter architecture.
• The design system wasn't used consistently. Many reached for standard widgets.

The rules were strict. Feature delivery comes first. Nothing already shipped may break. And the benefit has to be clear.

The strategy in phases

The team didn't just start. They worked in phases:

1. Stop new bad code. Brake first, then clean up.
2. Clean up the legacy code with automation, in many small PRs instead of one monster.
3. Build a quality culture that sustains itself.
4. Establish code ownership, deliberately later, once the benefits were visible.

I like this because the order makes sense. There's no point cleaning up for a year while new mess piles up next door.

Phase 1: custom lint rules

With analyzer_plugin, the team built their own lint rules including quick fixes. A simple example from the talk: every Cubit class must end in Cubit. Trivial, but it saves review arguments. The rules enforce team conventions and architecture, catch problems before review, and teach best practices along the way. AI agents also stick to the rules more reliably.

LeanCode published many of these rules as an open-source package, leancode_lint, on pub.dev.

Afterwards the team reported more consistent code, fewer bugs in new code, higher perceived velocity and fewer negative PR comments.

Phase 2: codemod instead of manual work

For the legacy code they used codemod, a kind of smart find-and-replace working on the syntax tree. A suggestor produces patches that you accept or reject in the CLI. Example from the talk: replace ElevatedButton with a custom AppButton, including argument mapping.

Other use cases: replacing hardcoded colors, migrating navigation from Navigator to a router, adding deprecations, adding missing semantic labels. The suggestors lived in their own package that all repos depend on. That way one change ran across roughly 50 repos with a single command.

AI and codemod together

This is where it got interesting for me. AI understands intent and context, but it isn't deterministic. Same input, different output. Plus cost and privacy concerns.

The speakers' approach: AI as the architect, codemod as the executor. The AI helps design the strategy and write the suggestors. The bulk of changes then runs deterministically and fast through codemod. My takeaway: let the AI build the tool, don't have it touch a thousand files one by one.

The safety net

The speakers named six layers:

1. CI/CD checks on every PR. For a refresher on the concept: What is CI/CD.
2. Test coverage for critical flows.
3. Golden tests, especially for design system changes.
4. Manual regression testing by QA.
5. Review by maintainers and tech leads with domain knowledge.
6. Peer review by people who know refactoring and linting.

They also mentioned Maestro, which lets developers or AI agents drive a running app and compare screenshots against a baseline.

One line stuck: trust nothing blindly, even if the PM signed off on refactoring time.

What I take from this for my own work

I don't work with 100 people. Still, it scales down. This is my opinion, not the speakers':

• Brake first, then clean up. Even in a small project, a strict analysis_options.yaml is worth it before I touch old code.
• Small PRs. A big rebuild in small steps is reviewable and reversible.
• Deterministic over magic. If I need to change something a hundred times, I write a script or a codemod. AI helps build it, not click through it.
• Tests before the rebuild. No net, no refactoring. I covered this in my post on solo developers: testing is the bottleneck.

For clients this means: a grown app isn't a write-off. With the right order, it can be improved piece by piece without the business stopping. If you're thinking about a new app, have a look at having an app built.

Conclusion

The Flutter team doesn't deliver big surprises, but it has a clear line: cleaner layers, faster tooling, more openness to agents and other screens. For me, decoupling Material and Cupertino is the most important signal.

And the banking case shows how to handle this kind of change day to day: in phases, automated, with a safety net and people who know the code. That holds for 100 developers just as much as for a team of one.

Frequently asked questions (FAQ)

This article was inspired by the interview panel on the Dart and Flutter roadmap and the talk "Flutter Refactors at Scale" by Agnieszka Forajter and Kamil Sztandur (LeanCode) at FlutterCon 2026.