Is it time for Flutter to leave the uncanny valley?

A frequent critique of Flutter is that its widgets, though impressively close, don’t feel quite native. They’re not wrong: Flutter UIs sometimes fail to replicate the nuances of the underlying platform perfectly. Then came the announcement of iOS 26 and Apple’s sweeping redesign: Liquid Glass. The React Native crowd once again proclaimed the “death of Flutter.”

Flutter can replicate these effects with shaders and surely will eventually. However, making an identical copy of Liquid Glass will be a huge task, and not much progress has been made yet. Liquid Glass has many new animations for menus, toolbars, and buttons, not just the new refractive materials. That sets the stage for a deeper question: How does Flutter keep up when native design leaps forward?

Native Liquid Glass via platform views

I decided to experiment: rather than reimplement Liquid Glass in Flutter, I embedded native SwiftUI components through platform views. I expected poor performance, issues with integration, or difficulty implementing it. When briefly discussing it with another former Flutter team member, he called it “a horrible idea.” But I decided it was still worth spending a weekend testing its viability.

Surprisingly, performance seems great. It runs without a hitch, both on my physical device and in the iOS Simulator. Why? Because Liquid Glass UI elements, by design, typically sit on top of all other content. That eliminates the more expensive operations, where Flutter draws content on top of the platform views.

Try it out yourself! You can install the cupertino_native plugin from Pub and start experimenting with Liquid Glass in your own Flutter apps today.

Could this be Flutter’s future?

I think so, at least as an interim solution before pure Flutter widgets catch up. I would love to see a hybrid approach. More advanced widgets, like toolbars, switches, sliders, and glass buttons, are made with platform views. Components that can more easily be replicated are made with pure Flutter. Things like icons can be rendered natively and then cached in Flutter. Minimizing the number of components drawn through platform channels will improve performance, but gains could also be made in Flutter itself. For instance, rendering of multiple platform views could be batched together, minimizing the number of switches between Flutter’s raster thread and UIKit’s main thread. That being said, I’m no expert in either Swift or how the platform views work under the hood.

Let’s build this together

I built cupertino_native under the umbrella of Serverpod’s open-source initiative. (If you haven’t heard about Serverpod, you should definitely check it out. It’s an awesome (free and open-source) way to build your Flutter app’s backend completely in Dart.) cupertino_native works and is a great proof of concept, but it was also vibe-coded in a weekend. So, it clearly needs both polish and more features. My estimation is that it will take less than a month to bring it to production quality with the right people on board. I’m running a startup myself, so my time for coding is very limited, but I’m happy to organize the effort. Please let me know if you are interested in helping out, and please spread the word so we can bring this to the Flutter community.

About the author

Viktor Lidholt is the founder and lead developer of Serverpod, an open-source backend written in Dart for the Flutter community. With a master’s in computer science and over 20 years of industry experience, Viktor has a solid background in software engineering. Before starting Serverpod, he worked at Google’s Flutter team in Silicon Valley. He has held talks and taught guest lectures on programming, app creation, and computer graphics at international conferences and universities such as MIT, Carnegie Mellon, and UC Berkeley.