This year, the mobile operating system landscape is undergoing a significant transformation. Both Apple and Google are rolling out ambitious new design systems: Apple’s Liquid Glass and Google’s Material 3 Expressive. These are both significant changes to the way apps are designed, and while it’s unclear how high the pressure will be to adopt them quickly, it undoubtedly puts the ball in Flutter’s court to see if it can adopt them.
Despite social posts showing rudimentary liquid glass renderers for Flutter just hours after WWDC, the Flutter team’s initial response may have surprised some:
“Currently, we are not actively developing Material 3 Expressive,” and “we are not developing the new Apple’26 UI design features in the Cupertino library right now.”
This begged the question: What will this mean for making native-feeling apps in Flutter?
It soon became clear that those worries were unwarranted, as Google announced that Flutter would be uncoupling from Cupertino and Material packages. These foundational UI components are being moved to their own independent packages, readily available on pub.dev.
It’s important to note that Material and Cupertino will still be considered “official” and fully supported by the Flutter team. Their plan is to add them to the flutter/packages repository, the same place they maintain packages like path_provider and image_picker. This ensures a consistent and reliable foundation for developers who choose to stick with these established design languages.
Why Developers Win With Decoupled UI
At Very Good Ventures (VGV), we’re really excited about this for a few reasons. First, all Flutter developers will get faster updates to these packages. UI changes and critical bug fixes for Material and Cupertino components will no longer be tightly coupled to the Flutter SDK’s stable release cycle. This means that new design specifications and essential updates can be shipped rapidly via pub.dev, rather than waiting for a Flutter release.
Second, developers will gain increased flexibility. They’ll have more granular control over precisely which UI libraries they import, making it more obvious for developers and companies adopting Flutter that they can build entirely unique design systems that perfectly match their brand. Developers can now import only the specific design languages they require, streamlining project dependencies and fostering a more modular and efficient approach to UI development.
Finally, this presents an amazing opportunity for 3rd-party UI libraries to shine, as the “official” packages will need to be installed just like packages from the community. It puts everyone on a level playing field. Some libraries we like are:
- macos_ui: macOS styled UI components
- fluent_ui: Windows styled UI components
- shadcn_flutter: beautifully designed components from shadcn/ui
It’s also a great time to think about making your own UI package specific to your designs and projects. At VGV, we’ve always built custom UI libraries for clients. In fact, it’s included in Very Good Start, and we use tools like Widgetbook to make it easy to share them with others and receive visual QA from designers.
Faster Updates, Greater Control
Flutter’s decision to decouple UI libraries marks a key moment for all Flutter developers. Rather than seeing this as a retreat from supporting new design systems, we see it as a strategic move that democratizes UI development within the Flutter ecosystem. This shift empowers developers with greater freedom to create interfaces that truly reflect their brand and design vision, whether by adopting third-party libraries or crafting custom solutions.
As the mobile design landscape continues to evolve with Liquid Glass and Material 3 Expressive, Flutter is positioning itself not as a rigid framework tied to specific design systems, but as a flexible canvas where any design language can thrive.
