We get this question in almost every discovery call: “Why Flutter and not React Native?”
Sometimes it comes from a CTO doing genuine due diligence. Sometimes it comes from a management team that assumes React Native is the same as React, and their web team can just “also do mobile.” Those are very different conversations.
Here’s what we’ve learned from shipping Flutter apps in production for years, and why we’ve never had a project where React Native would have been the better choice.
Side by Side
| Flutter | React Native | |
|---|---|---|
| Language | Dart | JavaScript / TypeScript |
| Created by | Google (2017) | Meta (2015) |
| Compilation | Native ARM code | JavaScript runtime (Hermes) |
| UI rendering | Own engine (Skia / Impeller) | Native platform components |
| Platforms | iOS, Android, Web, Windows, macOS, Linux | iOS, Android, Web (community), Windows/macOS (Microsoft) |
| Desktop support | Built-in, production-ready | Via Microsoft, less mature |
| BLE / hardware | Mature ecosystem | Available, fragmented |
| Learning curve | New language (Dart), but simple | Familiar if you know React |
| GitHub stars | 170k+ | 121k+ |
| Used by | Toyota, BMW, Google Pay, eBay | Meta, Shopify, Discord, Coinbase |
Tables are useful, but they don’t tell you what it’s actually like to build with each framework. Here’s what we’ve learned from real projects.
Flutter for Bluetooth Low Energy (BLE) Apps
When Classified Cycling came to us, they’d already done their research. They needed a companion app that would pair with wireless drivetrain hardware over Bluetooth Low Energy, push firmware updates over the air, and manage multiple device types across iOS and Android.
They chose Flutter before we were involved, specifically because of its BLE ecosystem. After years of development across multiple major releases, the app now manages connections to four different hardware types, integrates with two partner ecosystems (Shimano DI2 and TRP CMD), and handles firmware updates for all of them. The choice held up.
The BLE layer in Flutter handles the full lifecycle: scanning, connecting, authenticating with challenge-response over encrypted characteristics, reading battery levels, pushing firmware via Nordic DFU, and managing bonding differences between device types. It works reliably in outdoor conditions where Bluetooth is at its most unpredictable.
Could this have been built in React Native? Technically yes. But the Flutter ecosystem for BLE is more consolidated. One well-maintained library covers the full connection lifecycle. In React Native, you’re stitching together multiple libraries with different maintainers and different assumptions about how BLE state should be managed.
Flutter Performance: 60fps on Low-End Hardware
For the Lava auction platform, we built a real-time clock where the price drops every 50 milliseconds and hundreds of buyers bid simultaneously. A visual lag of 100ms means a buyer bids at the wrong price.
Flutter’s rendering engine let us split the clock into two independent paint layers: the expensive work (redrawing 100 price dots and labels) runs at the clock’s tick rate, while the cheap work (animating the active price indicator) runs at screen refresh rate. This architectural split is only possible because Flutter gives you direct control over the rendering pipeline. You’re not working through a bridge or waiting for a JavaScript runtime to process your frame.
The result: 60fps on the web, even on low-end devices. We wrote about this in detail in our auction clock deep dive.
In React Native, the New Architecture has closed much of the performance gap for typical apps. But when you need frame-level control over what repaints and when, Flutter’s rendering model gives you tools that React Native’s architecture doesn’t expose.
Flutter Desktop Support vs React Native
The Lava auction client ships on Windows desktop and web browsers from the same Flutter codebase. Same rendering, same WebSocket connection handling, same state management. The desktop support wasn’t an afterthought we bolted on. It was a first-class target from day one.
Ubuntu’s installer wizard is built with Flutter. Google’s own internal tooling uses it for desktop. When we tell clients “Flutter runs on desktop,” we’re not talking about an experimental feature. It’s production infrastructure.
React Native’s desktop story is improving through Microsoft’s contributions, but it’s still a separate effort with its own constraints. If multi-platform reach is a core requirement (not a nice-to-have), Flutter is the safer bet today.
Flutter Hybrid Apps: Wrapping Existing Web Infrastructure
Not every app starts from zero. Hubo, a Belgian DIY retailer with 160+ stores, already had a full e-commerce website. Building a native app that duplicated all that functionality would have been wasteful. Instead, we built a Flutter shell that wraps their existing web platform inside a native app, with select features implemented natively: push notifications, loyalty card, store locator.
Both Flutter and React Native support embedded web views. But Flutter’s advantage here is control. The native shell handles the app lifecycle, deep linking, and platform-specific features while the web views handle product browsing and checkout. The boundary between native and web is invisible to the user.
This hybrid pattern is common for companies that already have web infrastructure and want a mobile presence without rebuilding everything. Flutter makes the native parts feel native while leveraging what already exists.
Can Your React Team Build a React Native App?
We’ve never had a project where we recommended React Native over Flutter. But we have had conversations where management assumed React Native was the obvious choice because “we already have a React web team.”
React Native and React share the component model and JSX syntax. But mobile development is a different discipline. BLE connections, push notifications, background processing, app store deployment, platform-specific permissions, offline storage. A React web developer won’t be productive on these problems just because the syntax looks familiar.
The learning curve for Dart is real but short. Most developers are comfortable within a week. And what they gain is a framework where mobile, desktop, and web are genuinely equal citizens, not afterthoughts bolted onto a mobile-first architecture.
From Our Projects
These numbers come from production Flutter apps we build and maintain.
Migrating From React Native to Flutter
If you have an existing React Native app and you’re hitting performance ceilings, struggling with platform inconsistencies, or looking to expand to desktop and web, migrating to Flutter is worth considering. We help teams assess whether a migration makes sense and plan the transition without disrupting what’s already working.
A migration isn’t always the right call. But when your app’s requirements have outgrown what React Native handles well, Flutter gives you room to grow.
When We Recommend Flutter
- Performance matters (real-time UIs, animations, hardware integration)
- You need pixel-perfect consistency across platforms
- You’re building for more than just mobile (web, desktop, embedded)
- Bluetooth or IoT is involved
- You’re starting fresh with no existing mobile codebase
Our Take
The worst choice is picking a framework based on hype instead of your actual requirements. We chose Flutter because our projects involve custom rendering, hardware connectivity, and cross-platform reach beyond iOS and Android. For those use cases, Flutter gives us an edge we wouldn’t trade. If you want to learn more about how we work, see our Flutter development services.