Material and Cupertino Are Packages Now. November Brings Deprecation, Not Removal

If you've seen "Flutter is removing Material in November" in your feed, slow down. That's not what's happening, and the real schedule is easier to plan around.

Here is what the Flutter team has actually shipped and announced, checked against the official blog, the migration guide and pub.dev on October 1, 2026. Flutter 3.47, released August 12, made Material and Cupertino available as standalone packages, material_ui and cupertino_ui, both at 1.0. The copies inside the SDK still work. They're scheduled for formal deprecation in the Fall stable release in November. Removal comes later, and the Flutter team hasn't given a date for it.

So November is a warning. It's still worth migrating before then, for reasons more practical than "the docs said so."

What actually happened, in order

The decoupling wasn't a surprise. It's tracked in an issue titled "Move the material and cupertino packages outside of Flutter" (flutter/flutter#101479). 2026 is when it moved from plan to schedule:

• April 7, 2026: code freeze. The Flutter team announced that "all contributions to the Material and Cupertino libraries in flutter/flutter are frozen," and said the old code would be deprecated in the stable release after 3.44 and "deleted some time after that" (Flutter blog, April 7, 2026).
• May 20, 2026: Flutter 3.44. The release notes call 3.44 "the final set of updates to these libraries within the core framework" (What's new in Flutter 3.44).
• August 12, 2026: Flutter 3.47. material_ui and cupertino_ui "officially reached version 1.0 on pub.dev" (What's new in Flutter 3.47). The first versions were cut to match the frozen framework code, so the switch itself isn't supposed to change how your widgets look or behave (migration guide).
• November 2026: deprecation. In the 3.47 announcement's words, "the original design libraries inside the core SDK are scheduled for formal deprecation in the upcoming Fall stable release in November."
• Later: removal. The tracking issue for removal promises "a long and well-communicated deprecation period" and gives no version or date (flutter/flutter#172942).

There's a detail on the docs site that matches this reading. On the breaking changes index, "Migrate to standalone material_ui and cupertino_ui packages" sits under Not yet released to stable, not under 3.47. The packages shipped in August. The breaking part, deprecation, hasn't landed yet.

Why this is more than a rename

The import change is mechanical. What changes for you is everything around it.

The widgets now ship weekly. The 3.47 post says releases are "currently planned to land weekly," and pub.dev shows it. material_ui went from 1.0.0 on August 12 to 1.5.0 on September 28, with 1.5.0 adding Material 3 Expressive support for IconButton and high-contrast color scheme baselines (material_ui changelog). None of that is available through package:flutter/material.dart, which stays frozen. If your designers want the new Material components, you need the package.

The packages now set their own SDK floor. material_ui 1.4.0 raised its minimum to Flutter 3.47 and Dart 3.13. cupertino_ui 1.1.1 also requires Dart 3.13 (cupertino_ui versions). So "upgrade Flutter" and "upgrade the widgets" are now separate decisions, but they aren't fully independent.

Fast releases sometimes get pulled back. material_ui 1.3.0 and cupertino_ui 1.1.0, both published September 15, are listed as retracted on pub.dev (material_ui versions, cupertino_ui versions). Retraction exists for exactly this, and it's one more reason to commit your pubspec.lock and review design-package bumps like any other dependency.

Old and new types don't mix. This is the one that will cost you time. A ColorScheme from package:flutter/material.dart and a ColorScheme from package:material_ui share a name, but Dart treats them as different types. The migration guide is blunt about what that means for package authors: treat the switch as a major version bump, because even though the class names are the same, the symbols "are technically referenced from an entirely new library."

The dependency problem, in real issues

You can see the type wall in the Flutter issue tracker. When material_ui 1.0 shipped, dynamic_color still exposed the old ColorScheme, and apps that had migrated hit an analyzer error saying a ColorScheme? defined in the SDK's material library "can't be assigned to" a ColorScheme? defined in material_ui (flutter/flutter#191051). google_fonts hit the same thing with TextTheme (flutter/flutter#191067).

Both have since moved. dynamic_color 2.0.0 migrated to material_ui 1.0.0 (changelog), and google_fonts 9.0.0, published September 28, says it "Migrates to material_ui and cupertino_ui packages" and requires Flutter 3.47 and Dart 3.13 (changelog).

That cuts both ways. A dependency's "migrated to material_ui" release is a breaking change for any app that hasn't migrated yet, for the same type reason. If you plan to stay on the in-SDK libraries for a while, read the changelog before you accept a major bump of any UI package.

The Flutter team does ship a stopgap, MaterialUiCompatibilityBridge. It injects theme and localization data so unmigrated widgets can still call Theme.of(context). It can't fix type mismatches in public APIs. One report in the tracker, titled "MaterialUiCompatibilityBridge cannot cover API-signature coupling, only context lookups," describes a production app with about 18 widget-rendering plugins. After moving to material_ui 1.0.1 it hit three errors. The bridge fixed two. The third came from flutter_expandable_fab, whose ExpandableFab.location is passed straight into Scaffold as a Material type (flutter/flutter#191448). The Flutter team's answer was that the package itself migrating to material_ui "should resolve the issue."

Our take: the bridge buys you time for context-reading widgets. It won't save you from a dependency that's stuck, so find those early.

What to do before November

You don't need to rush any of this. It's just cheaper on a calm week than in the week deprecation warnings start filling your CI logs.

1. Upgrade to Flutter 3.47 and confirm your Dart version. Current releases of both packages need Dart 3.13. Run flutter --version and check that your pubspec.yaml environment allows it.

2. Audit your UI dependencies first. List every package that renders widgets or touches theming, then check each one's changelog or issue tracker for material_ui. Look hardest at anything whose public API takes or returns ThemeData, ColorScheme, TextTheme or another Material type. Those are the ones the bridge can't cover.

3. Run the official migration. From your package root, in a clean branch:

dart fix --apply --code=migrate_design_widgets

This rewrites imports from package:flutter/material.dart and package:flutter/cupertino.dart to the standalone packages (migration guide). If it doesn't add the dependencies for you, add them yourself:

flutter pub add material_ui
flutter pub add cupertino_ui

Your pubspec.yaml should end up with something like this (versions current as of October 1, 2026):

environment:
  sdk: ^3.13.0
dependencies:
  flutter:
    sdk: flutter
  material_ui: ^1.5.0
  cupertino_ui: ^1.1.1

If you'd rather migrate by hand, the import change is exactly this:

// Before
import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';
// After
import 'package:cupertino_ui/cupertino_ui.dart';
import 'package:material_ui/material_ui.dart';

4. Simplify your localization delegates. Material and Cupertino localizations moved out of flutter_localizations and into the new packages. The guide replaces the usual three delegates with one getter, which also covers the Cupertino and Widgets delegates:

import 'package:material_ui/material_ui.dart';
MaterialApp(
  localizationsDelegates: GlobalMaterialLocalizations.delegates,
  // ...
);

5. Add the bridge only if a dependency still needs it. If a dependency hasn't migrated yet and reads theme or localization data through context, wrap your app as the guide shows:

MaterialApp(
  theme: ThemeData(
    colorScheme: ColorScheme.fromSeed(seedColor: const Color(0xFF6750A4)),
  ),
  builder: (BuildContext context, Widget? child) {
    return MaterialUiCompatibilityBridge(child: child!);
  },
  home: const HomeScreen(),
);

Leave a TODO next to it. The bridge is a crutch for packages that haven't caught up, and you should plan to delete it.

6. Verify, then guard against regressions. Run flutter analyze and your widget and golden tests. Then make sure old imports don't creep back in from copied snippets or a teammate's branch. A simple CI check does the job:

! grep -rn --include='*.dart' -e 'package:flutter/material.dart' -e 'package:flutter/cupertino.dart' lib test

7. If you publish packages, ship a major version. Both the migration guide and the 3.47 announcement say to treat the move as a major release, and the dynamic_color and google_fonts releases above show why.

How this lands for FlutterGo projects

FlutterGo generates standard Flutter projects that you own: you can push them to your own GitHub repository or download them (export docs), and edit them in any editor. There's nothing special about that code. The same dart fix command, the same pubspec.yaml changes and the same dependency audit apply to it as to a project you wrote by hand. Don't assume an exported project has been migrated for you. Check its imports, and if they still point at package:flutter/material.dart, run the steps above on it.

This is the scenario we had in mind when we argued that you should judge an AI app builder by the repo it leaves you. Framework changes like this one land on your codebase, not on the tool that generated it. If the output is ordinary Flutter, an ordinary migration works.

One practical note: the code in our Flutter state management guide for 2026 imports package:flutter/material.dart, which is still correct on 3.47. When you migrate, swap that import for package:material_ui/material_ui.dart. The state management code itself doesn't change.

The short version

Flutter didn't pull Material out from under anyone. It shipped a replacement, set a deprecation date, and left removal open. The pressure to move comes from somewhere else: new widgets only land in material_ui, and popular packages are already switching types. Do the dependency audit this month, run migrate_design_widgets on a branch, and November becomes a version bump instead of an incident.

Dates, versions and quotes checked against the Flutter blog, docs.flutter.dev, pub.dev and the flutter/flutter issue tracker on October 1, 2026. Code snippets follow the official migration guide; they were checked against the docs but not compiled for this article.

• Flutter
• Flutter 3.47
• material_ui
• cupertino_ui
• Migration