Standalone material_ui and cupertino_ui: what the 1.0 split changes

Material and Cupertino used to be frozen inside the core SDK. That made design updates wait on the quarterly Flutter release train. In Flutter 3.47 both libraries reach 1.0 as standalone packages on pub.dev: material_ui and cupertino_ui.

Diagram: Standalone Material UI and Cupertino UI

You still get the SDK copies this release. The packages are opt-in. That is deliberate — the team froze contributions in April so the migration path could be boring.

Why the split matters in 2026

Three concrete outcomes:

Weekly design releases. Bugfixes and new components no longer wait for flutter upgrade.
Independent upgrades. An app pinned to an older SDK can still take the latest look and feel.
Style-neutral core. A leaner foundation for custom design systems (and for Liquid Glass / M3 Expressive-style shocks from platform vendors).

Migrate with dart fix

flutter pub add material_ui
# if you use Cupertino:
flutter pub add cupertino_ui

dart fix --apply --code=migrate_design_widgets

The fix rewrites imports from package:flutter/material.dart / cupertino.dart to the standalone packages. If pubspec.yaml is not updated automatically (an early known bug), add the deps by hand and run dart fix --apply again.

Bridge while dependencies catch up

Not every package you depend on will migrate on day one. Wrap the app:

import 'package:material_ui/material_ui.dart';

MaterialApp(
  builder: (context, child) => MaterialUiCompatibilityBridge(child: child!),
  home: const HomeScreen(),
);

Localization unbundles with the same move — Material/Cupertino delegates now live in the packages, and GlobalMaterialLocalizations.delegates includes the Cupertino and Widgets delegates.

Pitfalls

Treat this as a major release if you publish packages.
Core SDK copies are scheduled for formal deprecation in the November stable.
Run widget tests after import rewrites; theme APIs are the same, but library URIs are not.