Flutter has finally pulled Material and Cupertino out of the core SDK. Flutter 3.47, released on August 12, 2026, published the standalone material_ui and cupertino_ui packages at version 1.0 on pub.dev. The 1.0 releases match the frozen in-framework code, so for most apps the move is close to a drop-in. Contributions to the in-SDK libraries were frozen back in April, and Flutter 3.44 was described as the final set of updates to them inside the framework.
The date founders should put on the calendar is November. Flutter's 3.47 release notes say the original package:flutter/material.dart and package:flutter/cupertino.dart libraries are scheduled for formal deprecation in the Fall stable release in November. Deletion comes later, and no removal date has been announced. Your app will keep compiling through deprecation, but waiting until warnings flood CI is how mobile teams burn a release train.
Why Flutter made this change
The Flutter team's reasoning is practical. While the design libraries lived inside the SDK, widget fixes and new components were tied to quarterly Flutter releases, contributions moved slowly, and apps could not update their design system without upgrading the whole engine and framework. As standalone packages, Material and Cupertino can ship on their own schedule (weekly releases are planned) and follow semantic versioning. It also lays the groundwork for a style-neutral core widget catalog, which matters to anyone building a custom design system.
The release pace is already visible: a few weeks after 1.0, pub.dev lists material_ui 1.7.0 and cupertino_ui 1.1.3. That is the point of the change, and it's also why you should treat these packages like any other UI dependency you pin and review.
What changes for a production Flutter app
Imports move from SDK libraries to packages: package:material_ui/material_ui.dart and package:cupertino_ui/cupertino_ui.dart . Flutter ships a data-driven fix, dart fix --apply --code=migrate_design_widgets , that rewrites imports and adds the dependency. The release notes flag a known early bug where the tool doesn't update pubspec.yaml ; the workaround is to run flutter pub add material_ui (and cupertino_ui if you use it), then run dart fix --apply again.
The strategic win is upgrade hygiene. Engine and framework upgrades no longer force you to absorb design-library churn at the same time, and you can pick up newer Material or Cupertino widgets without a full SDK bump. That matters when Google Play and Apple toolchain requirements already tax the mobile calendar in 2026.
# Official migration entry point (Flutter 3.47+)
dart fix --apply --code=migrate_design_widgets
# Known early bug: if pubspec.yaml was not updated, add the packages yourself
flutter pub add material_ui # and cupertino_ui if you use it
dart fix --apply
flutter test # include golden tests for auth, paywall and settingsThe hard part is your dependencies
Your own code is the easy bit. The risk sits in third-party packages that still import package:flutter/material.dart or package:flutter/cupertino.dart . Old and new libraries define their own types, so a theme or localization object from one isn't automatically understood by widgets from the other.
The cupertino_ui migration guide covers two cases. First, use the GlobalMaterialLocalizations and GlobalCupertinoLocalizations classes from the new packages rather than from flutter_localizations . Second, if legacy packages in your tree still rely on the old Cupertino library, wrap the app in CupertinoUiCompatibilityBridge so CupertinoThemeData and CupertinoLocalizations resolve correctly. The bridge helps widgets that read theme or localization data through context ; it won't fix a package that passes old types around directly, so those need an upstream update or a temporary fork.
Package authors have their own note in the release post: if you publish a package in the ecosystem, treat the move to the standalone packages as a major release.
Team checklist
1. Land the dart fix on main in a dedicated PR, and don't let old and new imports mix across packages in a monorepo. 2. Pin material_ui and cupertino_ui versions deliberately and read their changelogs the way you would any UI kit's, because they will move faster than Flutter stable. 3. Add golden tests for critical flows such as auth, paywall and settings. The migration should be visually invisible, and goldens catch accidental theme regressions. 4. Audit plugins that import Material transitively, rebuild, and watch for duplicate type conflicts. 5. Tell designers that tokens and components may now change on package release notes, not only on Flutter stable blog posts.
Monorepo and white-label complications
Agencies and SaaS teams with several Flutter apps should migrate shared UI packages first, then the apps. Divergent import styles across packages create duplicate widget types and confusing analyzer errors, so appoint one owner for design-package versions across the fleet. White-label apps that fork themes should move tokens into the package theming model rather than patching SDK Material internals, since those internals are exactly what the decoupling is trying to stop you depending on.
Once you've migrated, add a CI gate that fails the build if app code imports package:flutter/material.dart again. A custom lint or a simple grep in the pipeline is enough.
How this fits the rest of the mobile calendar
November is busy for mobile teams. Google Play's extension for Play Billing Library 7 ends on November 1 for apps that requested it (we covered that in our Play Billing Library 7 deadline guide ), and App Store uploads already require Xcode 26. Sequence deliberately: finish the material_ui migration on the Flutter stable you already run, then schedule Flutter upgrades separately from Play and App Store policy work. If you're still deciding whether Flutter is the right bet at all, our React Native vs Flutter guide for founders walks through that call.
If migration isn't drop-in for your app, file an issue upstream. Silent local hacks become a permanent fork you'll be maintaining long after the in-SDK libraries are gone.
Founder takeaway
Flutter's Material and Cupertino decoupling is an October to November 2026 task for every production Flutter app. Ask your team for one mechanical PR with goldens before the November stable lands, a dependency audit for packages that still use the old libraries, and pinned package versions. Do that now and future Flutter upgrades stop being held hostage by design-system churn.
