Flutter Material and Cupertino Leave the SDK: What Changes for Your App

#flutter #dart #mobile #architecture

Short version: Flutter is moving Material and Cupertino out of the SDK and onto pub.dev as material_ui and cupertino_ui. Contributions to both libraries inside flutter/flutter froze on April 7, 2026, and both package names are already reserved by the flutter.dev publisher. Nothing in your app breaks today, but every import 'package:flutter/material.dart' in the ecosystem eventually becomes a package dependency.

What is the Material and Cupertino decoupling?

Flutter has always shipped its two design systems inside the framework. You import package:flutter/material.dart, you get Material's widget set, and you declare nothing. The decoupling project, tracked in flutter/flutter#101479, ends that arrangement and republishes both libraries as first-party packages on pub.dev.

The first milestone landed on April 7, 2026, when all contributions to Material and Cupertino inside flutter/flutter were frozen (Flutter blog). No further changes are allowed in the framework copies. Development resumes in flutter/packages once the new packages ship.

One correction worth making, because a lot of write-ups still get it wrong: the packages are named material_ui and cupertino_ui, not material and cupertino. Both already exist on pub.dev at version 0.0.1 under the verified flutter.dev publisher, currently unlisted placeholders (pub.dev). Even as placeholders, material_ui has collected 152 likes and 4.28k downloads.

Why move Material and Cupertino out of the SDK?

Release cadence is the headline reason. Flutter plans four stable releases for 2026 (Flutter blog), so a one-line design fix waits roughly a quarter to reach anyone. Contributors in the tracking issue documented exactly that, including a CupertinoAlertDialog divider rendering the wrong color because a value failed to resolve. Community design packages like fluent_ui and macos_ui ship on their own schedule and update far more often.

The architectural reason matters more. Material and Cupertino were entangled with each other and with the core widgets layer. An audit posted in the issue found 21 of Material's 179 source files importing Cupertino, while Cupertino imported Material zero times. Untangling that meant pushing shared behavior down into widgets, which is why the team has spent years relocating pieces like ToggleableStateMixin and RawMenuAnchor out of Material.

The payoff is a dependency inversion. Core widgets stop knowing about design systems, and design systems depend on widgets instead. That is what puts fluent_ui, yaru, and your own in-house design system on the same footing as Material.

![Two-lane diagram comparing how a design fix reaches your app today, waiting for the quarterly Flutter SDK release, versus after decoupling, when it ships as a material_ui release on pub.dev.]

What actually changes in your pubspec?

Two dependency lines and an import. That is the whole mechanical change for most apps:

dependencies:
  flutter:
    sdk: flutter
  material_ui: ^1.0.0
  cupertino_ui: ^1.0.0

// before
import 'package:flutter/material.dart';

// after
import 'package:material_ui/material_ui.dart';

The part that is not mechanical is what that import was hiding. package:flutter/material.dart re-exports the entire widgets library, so plenty of files import Material only to reach Column, Text, or StatelessWidget. Those files never needed a design system. They needed package:flutter/widgets.dart.

When does this hit your app?

Not yet, and not all at once. Flutter 3.44 shipped on May 18, 2026 with Material and Cupertino still inside the SDK. The in-framework copies are scheduled for deprecation in the stable release after 3.44, and deletion some time after that. The team has said it does not anticipate removing the old code within about a year (flutter/flutter#184093).

Four steps, and only the first one has happened:

![Four-step timeline of the Flutter Material and Cupertino decoupling: code freeze in April 2026, material_ui and cupertino_ui 1.0 published, SDK copies deprecated, SDK copies deleted.]

Three things to do before the packages land

Audit your material.dart imports. Any file that imports Material but only touches widgets primitives should move to package:flutter/widgets.dart now. This compiles on current stable, needs no new dependency, and removes those files from your migration entirely.
Package authors, plan for two support windows. If you publish something that re-exports Material or Cupertino widgets, you will need to work against both the SDK libraries and the new packages during the deprecation window. Decide early whether that is a major version bump or a compatibility shim, because your users will hit the deprecation warnings before you do.
Split your upgrade policy in two. The whole point is that you can hold material_ui at a version your design team signed off on while still taking SDK upgrades for performance and security fixes. Start treating the design system version and the Flutter version as two separate decisions.

FAQ

Will my app break when this ships?
No. The SDK copies stay through a deprecation window, and the Flutter team does not expect to delete them within about a year of the April 2026 freeze. You migrate on your own schedule.

What are the package names?
material_ui and cupertino_ui, both published by flutter.dev. Articles referring to material and cupertino predate the naming decision.

Is Google dropping Material design in Flutter?
No. Material stays first-party and Google-maintained. It moves onto its own release train so fixes and new Material specs land without waiting for a quarterly SDK cut.

Can I use material_ui today?
Not for real work. The published 0.0.1 is an unlisted placeholder, and its API reference still says the library is coming.

Does this shrink my app?
Probably not much. Tree shaking already drops unused widgets, so the real win here is architectural, not binary size.