Use case

Use Case 1:

As user of Flutter I don't want to be able to import material or cupertino. I want to enforce developers to use their own design system package. This is particularly common in big organisations where the design system is strict. Moving this out of "flutter" will avoid organisations developing their own scripts or workaround to prohibit importing material or cupertino into the main application.

Use Case 2:

As a Flutter developer I want to be able to update Flutter without updating material or cupertino. As Flutter has evolved, there are sometimes deprecations from material and in some applications, I don't want to update material (yet) but do want to update the framework itself.

Use Case 3:

Align with "flutter's vision":

Tim Sneath(@timsneath): Our general philosophy is to keep the framework small and encourage a package ecosystem just like this. This maximizes flexibility (e.g. being able to ship updates out of band of the main framework release).

The framework can be kept small by moving material and cupertino as their own independent packages.

Proposal

When using flutter you should not be able to do (when depending on flutter):

• import 'package:flutter/material.dart'
• import 'package:flutter/cupertino.dart'

Instead you should be able to do something as (if and only if material and cupertino are imported in pubspec.yaml):

• import 'package:material/material.dart'
• import 'package:cupertino/cupertino.dart'

Note: this would also allow the removal of uses-material-design: true.

Additional Resources

#56783 (comment)