Following the announcement of Apple’s Liquid Glass Design system at WWDC25, a fresh wave of debate has emerged over whether Flutter remains a viable choice for mobile development in 2025. Having worked with Flutter for the past 4 years, I have strong opinions on the topic which I’ll attempt to distill in this article. This article only reflects my personal views and should not be taken as universal truth.

The Argument

One of Flutter’s core strengths lies in its powerful UI rendering engine, which builds user interfaces entirely from scratch. Rather than relying on the host platform’s native UI components (like Android’s TextView or iOS’s UILabel), Flutter renders all user interfaces using its own renderer. The result? Smooth 60-120FPS animations on supported devices, custom UIs that look and feel the same on all platforms and complex transitions that do not rely on platform-specific APIs. This very feature allows developers craft highly bespoke and predictable user interfaces, offering a unified experience regardless of the underlying platform.

The bone of contention in this debate questioning Flutter’s validity is its bespoke rendering approach. Because Flutter’s doesn’t use native UI components, it does not deliver the true native user interface and experience of the host platform, but it replicates them. This criticism is valid to an extent; after all, Flutter’s built-in Material and Cupertino libraries are merely imitations of their native counterparts. Viewed from this angle, one of Flutter’s greatest strengths can easily be seen as a weakness.

However, should this concern carry as much weight as it seems to? Is Flutter’s philosophy of custom UI rendering a bug (mistake) and not a feature?

Design Systems

Before we take a deep dive into my thoughts on this argument, it is important to understand design systems. A design system is more than just a set of UI components — it’s a visual language that defines how a brand presents itself across digital experiences. It captures the essence of a brand’s identity, guiding how products look, feel and behave. Most modern companies have developed their own unique design systems to reflect their values and unify the experience they offer across their products and platforms they support.

From the Hawkins design system used at Netflix, to the Encore design system used at Spotify — different brands utilize different design systems to shape their interface and interaction patterns. These systems aren’t just aesthetic; they are strategic, allowing brands to fully control the experience they deliver to users.

For companies with a unique design system, a complete UI overhaul by one of the operating systems they support does not necessarily disrupt their core design language, unless strict adherence to native UI conventions is a core part of their product philosophy.

In fact, this is where Flutter shines, if viewed from a certain perspective. As a developer, I don’t want to recompile my app one day to find out that my app behavior and UI elements has changed simply because the host operating system introduced a new design language. Such unexpected shifts could alter the user experience in ways that no longer align my brand’s design system.

If a brand wants to evolve the experience it offers to its customers, it should be intentional — driven by its own product vision, not dictated by external platform updates.

This take might be debatable, but it’s one hill I’m willing to stand on until proven otherwise.

Touché! But can Flutter Access Native Views?

What if you need specific native views to blend seamlessly with your bespoke design?

Contrary to popular opinion, Flutter does allows you to embed native views within your Flutter app using Platform views. While this feature has its limitations and isn’t as performant as some other cross-platform solutions that rely on native bindings — it does support rendering for most native views.

So if you must integrate native components into your Flutter app, you could theoretically build a Flutter package to provide seamless access to these native views and their behaviors within your app. I won’t be surprised if there’s an ongoing Flutter community project already working towards this objective especially in response to Apple’s new Liquid Glass design system.

Hours after the WWDC events, attempts to recreate Apple’s Liquid glass design using Flutter began to surface online (Take the liquid glass renderer package for example). While I must admit that some of these attempts were not as fluid as the Apple’s native implementations, it still highlighted one of Flutter’s core’s strengths; rendering bespoke UIs from scratch. Flutter gives developers the creative freedom to replicate native experiences or even push beyond them with entirely original visual effects — shaping these experiences to their own unique styles.

Developer: I want this button to look all natural — like Liquid glass mixed with Leopard-skin patches. This better represents my brand.

Flutter: Sure! As long as you can build it, you can have it.

Beyond User Experiences

In my experience, most mobile applications serve as portals — tools that allow users access to value (in the form of digital products or services) delivered via remote servers. These apps typically collect data from the user’s device, send or retrieve data from a backend and render the response in a way that align’s with the brand’s identity and user experience goals.

This is where Flutter excels. It empowers developers to design and deliver a consistent, immersive experience across platforms without compromising on brand expression. With the added benefit of writing your UI once and running it everywhere, Flutter continues to stand out as one of the best technologies for crafting modern mobile experiences.

When Flutter might be a bad idea?

I recognize that this article may carry some bias, especially given my deep experience with Flutter. Still, it would be incomplete without acknowledging the scenarios where Flutter may not be the right choice.

One of Flutter’s core value propositions is its abstraction over the host platform that allows developers focus on building features without getting bogged down with the nuances of platform-specific APIs. However, this advantage starts to diminish when you’re building an app that relies heavily on native APIs. While Flutter Method Channels do provide a bridge between your Dart and native code, if you find yourself writing native integrations frequently, it might be an indicator that Flutter isn’t the best fit for that project.

As mentioned earlier, the User Interface and Experience provided by Flutter’s Material package and Cupertino package is only but a replication of the Android and iOS design system. Hence, if staying as close as possible to the visual language of the host operating system is a priority, Flutter might not be the ideal tool.

That said, a truly ‘pure’ native experience isn’t as critical for most applications as some developers suggest. In my opinion, only a few utility apps — those tightly integrated into the host Operating system — genuinely require a purely native experience to remain cohesive with the rest of the platform. Take “Raycast” for example; a macOS productivity app that closely interacts with system-level APIs.

In such cases, using the platform’s native tools isn’t just preferable, its necessary.

TL;DR

In conclusion, if your goal is to shape your user interfaces in a way that fully reflects your brand’s identity, with complete control over design and behavior — Flutter is an excellent choice. Its custom rendering engine gives you the freedom to build unique and consistent experiences across platforms.

However, if aligning closely with the host platform’s native design system is a top priority for your product — either for UI cohesion or deep integration with platform APIs — then a native or alternative cross-platform approach might serve you better.

Choose your tools based on your product’s core needs, not just popular opinion.

Flutter vs. Native After WWDC25

Table of contents