Flutter 3.50: one component library to upgrade them all

Flutter 3.50 moves Material and Cupertino out of the framework. material.dart and cupertino.dart are deprecated, and the widgets now live in the material_ui and cupertino_ui packages. For one app, that's an afternoon. For a company that maintains a lot of apps, it could easily be weeks: every app, every button, every dialog, every text field, checked again.

For us it isn't, and the reason is not this release. It's a decision we made long before it.

When every app talks to Material

If your apps use Material widgets directly, a change like this lands in every one of them. The migration itself is automated (dart fix --apply --code=migrate_design_widgets), but the risk isn't in the imports. It's in what changes underneath: a dropdown that is now disabled differently, text that suddenly hyphenates, a widget that looks a few pixels off. To be sure nothing broke, you would have to validate every component in every project.

One component library to rule them all

Our apps don't talk to Material. They talk to impaktfull_ui, our open-source component library, and impaktfull_ui is the only thing that talks to Material and Cupertino. So the upgrade happens in one place:

1. impaktfull_ui moves to material_ui and cupertino_ui.
2. Its golden tests render every component in every theme it ships. If something looks different, we see it there, once.
3. If impaktfull_ui's own API needs to change, the change ships with a fix in its fix_data.yaml, so dart fix updates the apps too.
4. We release impaktfull_ui.

Then every app gets the same small upgrade: a new Flutter, a new impaktfull_ui, dart fix, a quick look at the app. No component validation per project, because the components were validated in the library. Twenty apps don't mean twenty migrations; they mean one migration and twenty version bumps.

It pays off every release, not just this one

This release makes the point loudly, but it's true every time Flutter changes something visual, every time a design detail needs fixing, every time a client wants a new look. One library, tested once, used everywhere. It costs more at the start than putting Material widgets straight into an app. It pays that back the first time something like 3.50 comes along.

The rest of the release, briefly

• The CocoaPods trunk goes read-only in December 2026: switch Swift Package Manager back on if you turned it off.
• Android release builds ignore Intent extras like route and dart_entrypoint: test your deep links in a release build.
• Dart 3.14 adds dart migrate, which moves a package forward one SDK version at a time.

Everything else is in the official posts: What's new in Flutter 3.50 and Announcing Dart 3.14.