The Flutter UI toolkit

Flutter is Google's open-source UI toolkit for building iOS, Android, web, and desktop apps from a single codebase written in Dart. Its defining choice sets it apart from most frameworks: instead of borrowing each platform's native widgets, Flutter draws every pixel itself with a high-performance rendering engine. One codebase produces the same interface everywhere. It is one of the main routes covered in mobile app development.

How Flutter works

A Flutter app is a tree of widgets. Everything on screen, from a button to the padding around it, is a widget, and you compose them declaratively: you describe what the UI should look like for a given state, and the framework figures out the smallest set of changes to get there. If you have written React, the mental model will feel familiar.

Underneath sits the rendering engine, and this is where Flutter diverges from the pack. Rather than mapping your widgets onto iOS and Android controls, the engine paints the interface directly onto a canvas. That is why a Flutter screen looks identical on both platforms down to the pixel, and why animation stays smooth without wrestling each OS's quirks.

Dart makes the performance work. For release builds it compiles ahead of time straight to native ARM or x86 machine code, so there is no interpreter in the hot path. During development it switches to just-in-time compilation, which powers stateful hot reload. You save a file and the running app updates in under a second without losing its place. That tight feedback loop is one of the reasons teams stay in Flutter once they start.

The rendering engine, Skia and Impeller

For most of its life Flutter rendered with Skia, the same 2D graphics library that powers Chrome and Android. Skia is proven, but it had a persistent weakness: shaders compiled on first use, which showed up as visible jank the first time a complex animation ran.

Google's answer is Impeller, a newer engine that precompiles shaders so that first-run stutter largely disappears. Impeller is now the default renderer on modern iOS and on Android devices running API 29 and up with Vulkan, and it falls back to the legacy renderer on older hardware. Flutter 3.38, released in late 2025, deprecated the option to opt out of Impeller on Android, which signals the tail end of the Skia-to-Impeller transition. In practice you rarely touch any of this. It is the machinery that makes your animations run clean.

What you can build with Flutter

From one Dart codebase Flutter targets six platforms: iOS, Android, web, Windows, macOS, and Linux. Mobile is the heartland and the most battle-tested, but web and desktop reached stable support and now ship in production apps, not just demos.

Flutter is a particularly strong fit when the interface carries the product:

• Highly custom, brand-driven UI where you want full control over every pixel
• Motion-heavy apps with rich, fluid animation and custom transitions
• Products that need pixel-identical screens across iOS and Android
• Teams that want a single toolkit spanning mobile, web, and desktop

Plenty of large apps run on it. Google Pay, Alibaba, BMW, eBay Motors, and the digital bank Nubank have all shipped Flutter in production, which is a reasonable signal that it scales past a prototype.

Flutter vs React Native vs native

The choice usually comes down to Flutter, React Native, or true native, and the honest framing is trade-offs rather than a single winner.

• Flutter gives you Dart, one codebase, and custom rendering. You get pixel-consistent UI and smooth motion, at the cost of a smaller talent pool and some binary-size overhead.
• React Native gives you JavaScript, one codebase, and real native components bridged from JS. It feels native on each OS and draws on a huge developer base, but very performance-sensitive work can hit the bridge.
• Native (Swift and Kotlin, separate codebases) gives you the deepest platform access and the highest performance ceiling, and costs you two codebases plus two specialist teams.

Framed against React Native specifically, it comes down to ecosystem fit: Dart and a self-drawn UI on one side, JavaScript and native components on the other. Both are solid answers to the native versus cross-platform question, and the right pick depends on your team and how custom your design has to be.

When Flutter is the right call

Reach for Flutter when the design is ambitious and consistency across platforms matters. If your product leans on a distinctive visual identity, elaborate animation, or a UI that must look identical on an iPhone and a budget Android phone, Flutter's own rendering engine is a genuine advantage rather than a novelty.

It is also a strong default when one team needs to ship both mobile platforms fast without maintaining two native codebases. Startups use exactly this to get a polished, near-native app in front of users on a single budget, which is often the deciding factor for an early mvp.

Where it fits less cleanly: if your team already lives in JavaScript, React Native may onboard faster; and if the app is a thin skin over the newest native SDKs, going native can be the shorter path.

The trade-offs to weigh

No framework is free of tension, and Flutter's are worth naming up front.

Because it draws its own widgets, matching a platform's exact native look and behavior takes deliberate effort. Flutter ships Material and Cupertino widget sets that get you most of the way, but pixel-perfect parity with the very latest native patterns can mean custom work.

Your team also has to adopt Dart. It is a pleasant, approachable language, especially if they know Java, C#, or TypeScript, but the hiring pool is smaller than JavaScript's, and that can matter when you scale a team. Finally, Flutter apps carry the engine and Dart runtime, so binaries run a bit larger than a minimal native app. For most products none of these is a dealbreaker; they are simply the price of the model, and worth weighing before you commit.

When the design is the point and you want it identical everywhere, building it is Flutter app development.