Disclaimer:
I'm aware of #101479 that talks about this same topic, but it doesn't do justice to the whole issue here I wrote in detail to why we need this change
Use case
Flutters Cupertino & Material packages are hard to change frequently, especially for minimal changes that could make a huge difference for the developers and users, so the solution is that they should be decoupled from the Flutter core packages and be a separate pub package.
Proposal
Flutter has a set of core packages built into it, including the UI packages Material and Cupertino which are the corresponding UI designs for iOS and Android, but when it comes to using platform native UI on desktop there are packages but not tightly coupled to the framework for Windows there is the flutent_ui package and for macOS there is the macos_ui.
Why am I mentioning the macOS and Windows UI packages?
if you notice, when checking out these packages on pub.dev, the first thing you will immediately notice is how recent the package is updated, even better check the versions tab and look at how frequently they get updated, why is it important on how frequent these packages are updated? It's because they're not any package, they're UI packages, and the UI is a crucial part of an app since it's what the user stares at the whole duration of using your app, so we must do our best to make sure that it's flawless or at least there aren't any disturbing UI visually and function wise.
Ok cool, but what does this have to do with Cupertino & Material?
Cupertino & Material being tightly coupled to the Flutter core packages may seem nice at first glance, but has but a huge downside, which is making their releases become tied to Flutters releases, and we're talking about stable releases, which have an average of 3.1 months between every release, which in comparison to the fluent_ui and macos_ui I mentioned above is way bad, those get updated every few days and we have Cupertino and Material getting updates every 3 months, which leaves lots of issues in the dust without quick fixes.
Well what about cherry picks, they can be enough?
No they can't while some fixes like #148916 got cherry picked, many others can't be, because it can be risky to cherry pick sometimes, there are lots of internal dependencies .
Recent cases where them being decoupled would've been useful:
Flutter 3.29 recently introduced a new named constructor for Cupertino called CupertinoSliverNavigationBar.Search(), this widget had incorrect visuals that include a misaligned icon, wrong positioning and horizontal padding, missing APIs that make use of the search field, PRs were created to fix them, it got the missing APIs and visuals fixed, but users can't get these changes immediately, they have to wait for a pretty long process for the PRs to get merged to Flutter, aaaaand now they have to wait for the next stable release, if it were a package on pub.dev, the PRs shouldn't take significantly less time to get merged since the package is more lightweight and isn't full on sensitive dependencies inside the framework.
heres are 3 screenshots with red guidelines from the iOS native settings app applied:
iOS native settings app:
CupertinoSliverNavigationBar.search() on 3.29 release before the later opened PRs to fix it.
CupertinoSliverNavigationBar.search() after the changes from the PRs are applied.
as you can see the changes are minimal but we have to wait a long duration to get them.
another case is with the CupertinoAlertDialog, there has been a long lasting issue with its horizontal divider as you can see in this screenshot it uses the wrong color:
left is native, right is Flutter:
the reason why it's not using the correct color is that the dividers color isn't resolving, that's it, it did get fixed in a new PR though here is the after result:
well if it's that simple why didn't it get fixed early on?
lets say someone ones to fix this issue in a PR, it might be a 1 line fix, but the whole process might be tedious because of how things depend on each other, and you have to wait, other things might break, so it's not as straightforward at it seems for a tiny fix.
Why didn't the Flutter team solve it then early on since it's so simple?
I asked myself this question and found an answer after some basic observation, the Flutter team as we know doesn't have that much resources, they maintain lots of first party things heavily, Flutter itself is huge, lots of things need fixing, maintaining, things with way higher priorities, so a tiny problem with a divider color may seem unimportant to them because they're deep work on the Flutter SDK, but us developers who build apps on the daily see this issue as a big one, so in the next section, I'm proposing my ideal way to solve both parties problems, take a lot of work off the Flutter teams back, and make those app developers life easy by getting fixes faster and making the ability for them to fix issues themselves easier and quicker.
Introducing widgets.dart
yes I know it exists, but this time give it steroids, widgets.dart has always been a base for UI packages, but not that good as a base, since other packages implements of things on their own for example buttons, if widgets.dart had a button implementation for example that is fully fledged, with everything you'd want a button to do, make it headless, no specific UI design, and make extendable by cupertino and material and any other current or future UI packages, and not just buttons, widgets.dart should the ultimate widget base, it should have everything, then material and cupertino will reuse the functionalities from it and paint it with all the colors and behaviors they like, I've read comments with previous proposals that decoupling material and cupertino will fragment the community and cause fragmentation and multiple implementations of the same functionality or behavior in multiple UI packages, a super widgets.dart will solve this.
so the flutter team majorly focuses on widgets.dart and the implementations can be extended easily in cupertino material, it will even encourage more people to create custom UI package since it will be easier since they don't have to reinvent the wheel again.
in conclusion Cupertino & Material will be more lightweight which will result in solving issues to be easier which will encourage lots of people to contribute to cupertino and material packages and we can see with fluent_ui and macos_ui lots of people contribute to them and changes ship quickly because they're lightweight.
it may be a big task to do, but in the long run it will benefit both the Flutter team and us who built with Flutter.
Disclaimer:
I'm aware of #101479 that talks about this same topic, but it doesn't do justice to the whole issue here I wrote in detail to why we need this change
Use case
Flutters Cupertino & Material packages are hard to change frequently, especially for minimal changes that could make a huge difference for the developers and users, so the solution is that they should be decoupled from the Flutter core packages and be a separate pub package.
Proposal
Flutter has a set of core packages built into it, including the UI packages Material and Cupertino which are the corresponding UI designs for iOS and Android, but when it comes to using platform native UI on desktop there are packages but not tightly coupled to the framework for Windows there is the flutent_ui package and for macOS there is the macos_ui.
Why am I mentioning the macOS and Windows UI packages?
if you notice, when checking out these packages on pub.dev, the first thing you will immediately notice is how recent the package is updated, even better check the versions tab and look at how frequently they get updated, why is it important on how frequent these packages are updated? It's because they're not any package, they're UI packages, and the UI is a crucial part of an app since it's what the user stares at the whole duration of using your app, so we must do our best to make sure that it's flawless or at least there aren't any disturbing UI visually and function wise.
Ok cool, but what does this have to do with Cupertino & Material?
Cupertino & Material being tightly coupled to the Flutter core packages may seem nice at first glance, but has but a huge downside, which is making their releases become tied to Flutters releases, and we're talking about stable releases, which have an average of 3.1 months between every release, which in comparison to the fluent_ui and macos_ui I mentioned above is way bad, those get updated every few days and we have Cupertino and Material getting updates every 3 months, which leaves lots of issues in the dust without quick fixes.
Well what about cherry picks, they can be enough?
No they can't while some fixes like #148916 got cherry picked, many others can't be, because it can be risky to cherry pick sometimes, there are lots of internal dependencies .
Recent cases where them being decoupled would've been useful:
Flutter 3.29 recently introduced a new named constructor for Cupertino called CupertinoSliverNavigationBar.Search(), this widget had incorrect visuals that include a misaligned icon, wrong positioning and horizontal padding, missing APIs that make use of the search field, PRs were created to fix them, it got the missing APIs and visuals fixed, but users can't get these changes immediately, they have to wait for a pretty long process for the PRs to get merged to Flutter, aaaaand now they have to wait for the next stable release, if it were a package on pub.dev, the PRs shouldn't take significantly less time to get merged since the package is more lightweight and isn't full on sensitive dependencies inside the framework.
heres are 3 screenshots with red guidelines from the iOS native settings app applied:
iOS native settings app:
CupertinoSliverNavigationBar.search() on 3.29 release before the later opened PRs to fix it.
CupertinoSliverNavigationBar.search() after the changes from the PRs are applied.
as you can see the changes are minimal but we have to wait a long duration to get them.
another case is with the CupertinoAlertDialog, there has been a long lasting issue with its horizontal divider as you can see in this screenshot it uses the wrong color:
left is native, right is Flutter:
the reason why it's not using the correct color is that the dividers color isn't resolving, that's it, it did get fixed in a new PR though here is the after result:
well if it's that simple why didn't it get fixed early on?
lets say someone ones to fix this issue in a PR, it might be a 1 line fix, but the whole process might be tedious because of how things depend on each other, and you have to wait, other things might break, so it's not as straightforward at it seems for a tiny fix.
Why didn't the Flutter team solve it then early on since it's so simple?
I asked myself this question and found an answer after some basic observation, the Flutter team as we know doesn't have that much resources, they maintain lots of first party things heavily, Flutter itself is huge, lots of things need fixing, maintaining, things with way higher priorities, so a tiny problem with a divider color may seem unimportant to them because they're deep work on the Flutter SDK, but us developers who build apps on the daily see this issue as a big one, so in the next section, I'm proposing my ideal way to solve both parties problems, take a lot of work off the Flutter teams back, and make those app developers life easy by getting fixes faster and making the ability for them to fix issues themselves easier and quicker.
Introducing widgets.dart
yes I know it exists, but this time give it steroids, widgets.dart has always been a base for UI packages, but not that good as a base, since other packages implements of things on their own for example buttons, if widgets.dart had a button implementation for example that is fully fledged, with everything you'd want a button to do, make it headless, no specific UI design, and make extendable by cupertino and material and any other current or future UI packages, and not just buttons, widgets.dart should the ultimate widget base, it should have everything, then material and cupertino will reuse the functionalities from it and paint it with all the colors and behaviors they like, I've read comments with previous proposals that decoupling material and cupertino will fragment the community and cause fragmentation and multiple implementations of the same functionality or behavior in multiple UI packages, a super widgets.dart will solve this.
so the flutter team majorly focuses on widgets.dart and the implementations can be extended easily in cupertino material, it will even encourage more people to create custom UI package since it will be easier since they don't have to reinvent the wheel again.
in conclusion Cupertino & Material will be more lightweight which will result in solving issues to be easier which will encourage lots of people to contribute to cupertino and material packages and we can see with fluent_ui and macos_ui lots of people contribute to them and changes ship quickly because they're lightweight.
it may be a big task to do, but in the long run it will benefit both the Flutter team and us who built with Flutter.