We build Flutter apps for products where the interface is the product: custom branded screens, heavy animation, and one design that must look the same on iPhone, Android, and sometimes web or desktop. This page explains how Flutter works, where it beats React Native, where it does not, and what we watch for in delivery. The side-by-side with the other framework is in our React Native vs Flutter comparison.
How does Flutter work?
Flutter apps are written in Dart. Instead of mapping your layout onto the system’s own buttons and lists, Flutter draws every pixel itself. On iOS it does this with Impeller, its own rendering engine, which Flutter’s documentation lists as the only supported engine there. On Android, Impeller is the default on API level 29 and above, with a fallback to the older OpenGL renderer on earlier versions or devices without Vulkan.
Two consequences follow. The UI renders identically on every platform because the same code draws it. And an operating system update that changes native controls does not change your screens, which also means you do not get new system looks for free.
When does Flutter beat React Native?
| Situation | Better fit | Reason |
|---|---|---|
| Custom brand UI with motion and gestures | Flutter | One rendering path, so animation behaves the same everywhere |
| Pixel-identical design on iOS and Android | Flutter | Native controls are not in the way |
| Team already writes React and TypeScript | React Native | Skills and some logic carry over |
| App must feel like each system’s own apps | React Native or native | Flutter needs deliberate work to match platform conventions |
| One codebase for mobile, web and desktop | Flutter | Same Dart code and widget set across targets |
| Heavy use of niche native SDKs | Native or React Native | Flutter reaches them through plugins you may need to write |
Neither wins on raw speed for typical apps. Pick on team skills and how custom the interface is. Our React Native service page covers the other side of that choice.
What do we build in Flutter?
- Design-led consumer apps with custom components, transitions and onboarding.
- Apps with custom drawing, such as charts, canvases, games-like interfaces and configurators.
- Multi-target products that share a core between mobile apps and a web or desktop client.
- Add-to-app modules, where a Flutter screen set embeds inside an existing native app.
Which technologies do we use with Flutter?
| Concern | Our default | When we choose differently |
|---|---|---|
| State management | Riverpod | Bloc where the team already uses it |
| Navigation | go_router | Native navigation in add-to-app modules |
| Networking | Dio with typed models | Generated clients when an OpenAPI spec exists |
| Local data | Drift (SQLite) | Secure storage for tokens |
| Testing | Unit, widget and integration tests | Golden tests for design-critical screens |
| Release | Fastlane, Codemagic or GitHub Actions | Your existing CI |
Golden tests fit Flutter well: they compare rendered widgets against reference images, so a design regression shows up in the pull request instead of on a customer’s phone.
What are the real trade-offs?
Dart is its own language, so hiring and onboarding draw on a smaller pool than JavaScript and TypeScript. Plugins for platform features vary in quality, and a missing plugin means a native Swift or Kotlin bridge written by someone on the team. App size starts higher than a purely native app because the engine ships inside the binary. Accessibility needs explicit attention, since Flutter builds its own semantics tree rather than inheriting the system’s controls. Text input, dark mode and platform gestures work, but each needs a check on both systems.
We plan for these at the start: one engineer owns the native bridge layer, and the device test pass includes screen readers on both platforms.
How do we test and release a Flutter app?
Builds are tested on physical iPhones and mid-range Android phones, because frame timing on a flagship hides problems. We profile with Flutter DevTools in profile mode, which is the only mode that reflects real performance, and fix jank in the screens it shows. Release runs through the same stores as every app: TestFlight and App Store review for iOS, internal and closed testing tracks and a staged rollout on Google Play. See our mobile development overview for the shared release practice.
What does Flutter cost to own?
Scope drives price. The factors that matter most here: how many custom components the design needs, how many native SDKs must be wrapped, whether web or desktop targets are in scope, and how often Flutter and plugin versions need upgrading. A design system built once and reused across screens lowers cost. A fresh custom widget on every screen raises it. Ranges by app type are in the mobile app cost guide, and we give a written estimate after a scoping call.
Do we have Flutter proof?
We have not published a Flutter case study. Our published mobile cases are in React Native, and we say so rather than borrow their numbers. If your product suits Flutter, we propose a short prototype of the hardest screen first, so you judge the rendering and animation on your own device before committing.
How can you add Flutter engineers?
Hire mobile developers with Dart and Flutter experience, or take a dedicated mobile team. For the interface itself, our mobile app designers design for Flutter’s component model. Rates are $50 to $150 per hour depending on seniority and role.
