Why Flutter doesn’t use OEM widgets

A developer’s journey from skepticism to excitement for the future of non-OEM widgets, and bespoke mobile design

Nov 16, 2017 · 14 min read
Modern, consistent Material Design on a phone shipped 4 years before Material Design was unveiled


Before joining the Flutter team early in 2017, I developed mobile applications for years — some in a fast-paced startup agency, and more recently for large-scale consumer applications inside Google.

  • “Won’t you have to keep playing catch-up vs Google and Apple who have hundreds of smart people building new UI?”
  • “We want to build fast but we can’t compromise on UI quality or performance”
  • “Designing uniform UI for both simultaneously will end up with the lowest common denominator”

What do the People want?

Before diving head-first into how Flutter is built and why OEM widgets weren’t a part of it, it’s worth taking a step back and spending a brief moment reflecting on the end goal of all this.

A collection of 2016’s design award winning apps in both Android and iOS forms

1. Declarative API

While OEM toolkit views implement a mutable imperative style of UI API, Flutter is excited and inspired by the recent popularity of new UI programming paradigms as a solution to manage the scalability of UI logic as the number of input signals affecting the UI output of today’s apps increases in both number and complexity. As such, Flutter uses a reactive, declarative style UI API.

2. Modularity

To empower the developers to be experience creators rather than assemblers, the Flutter toolkit is built by composition with accessible APIs at every layer.

3. Predictable consistency

The customer is always right. In other words if the app creator, the domain expert of the problem he/she is trying to solve, has already decided on the look and feel of the solution then that solution is consistently, predictably and exactly what the developer and their users should get. And that should be true regardless of compat library versions, regardless of platform, regardless of OS versions, regardless of phone manufacturer skinning(unless the developer wants them to be different).

4. Don’t surprise the user

We might call the previous section “don’t surprise the developer”. Though it’s just as important as “don’t surprise the users” as well.

5. Fluid motions

As current design trend are indicating, motion design and development are treated as a first-class citizen, along with UI performance. In Flutter, motion expressivity and performance is deeply embedded in the API design and higher level widgets.

How to get there

With now the established primary goal of making it easy for developers to create any custom UI, we explore some possible implementation options. While various approaches can get us very close, we really wanted to hit all the principles listed above to offer the best workflow and experience.

Approach 1 — Web technology

Fixed on solving the mobile development productivity problem for many years, the Flutter team includes many web technology luminaries. So we first investigated the popular ‘hybrid’ cross-platform approach. The team spared no expense stripping down various web components to fit the mobile needs. But maintaining the existing compatibility of the web’s extensive flexibility made it too difficult to achieve the necessary performance characteristics, especially with respect to motion when web components are molded to a native look and feel.

Approach 2 — Native widget wrapping

The second approach involved wrapping OEM widgets with another full-featured declarative-style UI API in a common third language.

Approach 3 — full stack rendering

In order to fully achieve the all the traits of a framework we think will be the best for expressing mobile UI, the Flutter team experimented further and pushed into more ambitious territories beyond reusing OEM widgets.

Performance is literally right in our faces as we develop the framework
  • Components like app navigation bars (either skinned or unskinned) by default match the text alignment and paddings etc of the OS
  • Page transitions’ animation curves, directions, durations, opacity changes etc match the OS
  • Platform specific behaviors like edge swipe to go back, status bar tap to scroll up on iOS and tap outside dialogs to dismiss on Android work as expected
A few examples of Flutter’s OS adaptiveness

Design implications

Given now these design choices of the Flutter framework, let’s look forward again and evaluate their other exciting impacts for the Flutter developers.

Development speed

Thanks to the declarative and reactive UI style, and Dart’s properties, Flutter apps is hot-reloadable and can be reloaded quickly and without losing application state. Because of the declarative style’s central ability to interpolate between desired resting states, hot-reload works even in the middle of animations or other transient tasks whose present state is unknown to the explicit user program.


A UI toolkit built by composition is inherently more testable. Semantic UI testing have always been a huge headache for native mobile developers using a variety of tacked-on mechanisms like EarlGrey, Espresso, UI Automator, KIF etc. Even then, you can only write unwieldy, flaky top-level integration tests that are costly to run in both time and resource because they require a full application runtime (which again triggering the dreaded context switch when doing test driven development).

Developer control

And I felt necessary to mention developer control again because this has bitten me so frequently in the past :)

Environment decoupling

Flutter decouples the UI toolkit from the OS.

Consistent Material Design (or your design) on phones made way before Material Design existed
iOS 11 on an old, single-core 1GHz Android phone before iOS 11 came out


While there are many ways of creating a UI framework, I gradually learned that Flutter’s goal of creating the best tool to build tailored UI experiences led the team through a number of conceptual iterations that ended with the version we have today.


Flutter is Google's mobile UI framework for crafting…


Flutter is Google's mobile UI framework for crafting high-quality native interfaces on iOS and Android in record time. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source. Learn more at https://flutter.dev


Written by



Flutter is Google's mobile UI framework for crafting high-quality native interfaces on iOS and Android in record time. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source. Learn more at https://flutter.dev

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store