Writing
React Native or Flutter: a decision framework, not a benchmark
Both are fast enough for almost every product. The decision is made on hiring, native integration depth, UI fidelity and long-term maintenance — with a checklist for testing your own case in a week rather than trusting somebody else's numbers.
5 min read
Cross-platform benchmark posts age badly and transfer poorly. They measure a list-scrolling demo on one device, at one framework version, and the ranking flips with the next release of either. Meanwhile the decision gets made for reasons the benchmark never touches.
Performance is not the deciding factor, and here is why
Both frameworks compile to native UI or draw directly to the screen, both handle 60fps lists, and both are limited by the same things in practice: image decoding, network latency, and how much work you do on the UI thread.
| React Native | Flutter | |
|---|---|---|
| UI | Real platform widgets | Own rendering engine, draws every pixel |
| Looks native by default | Yes — it is native | Only if you choose the matching widget set |
| Follows OS design changes | Automatically | When the framework ships them |
| Pixel-identical across platforms | No | Yes — that is the design |
| Language | TypeScript | Dart |
| App size floor | Smaller | Larger — the engine ships with it |
The row that decides most cases is the third or the fourth, depending on what you are building.
The four questions that actually decide it
One: what does your team already write?
If you have a web team writing React and TypeScript, React Native means shared language, shared tooling, shared types with your backend, and shared people. That is a compounding advantage that no framework benchmark measures.
If you have no JavaScript team, that advantage is zero and Dart is a perfectly good language to hire into.
Two: how much native integration do you need?
| Integration depth | Implication |
|---|---|
| Camera, location, notifications, storage | Solved in both; mature packages exist |
| Background sync, geofencing | Real platform work in both; budget for it |
| Bluetooth, NFC, hardware SDKs | Check the specific vendor SDK has a maintained binding |
| Heavy native processing | Whichever has the better bridge for your specific case |
The failure mode here is discovering in month four that the one SDK your product depends on has a binding that was last updated two years ago. Check that before choosing, not after.
Three: does the UI need to be native, or consistent?
This is a product decision that people try to make as a technical one.
- Native fidelity — the app should feel like the platform, follow its conventions, and pick up OS design changes for free. That argues for React Native.
- Brand consistency — the app should look identical everywhere and match a design system precisely. That argues for Flutter, which draws every pixel and therefore owes the platform nothing.
Neither is better. They are different products.
Four: who maintains it in three years?
Upgrade cost is the recurring bill
Both frameworks ship breaking changes. Ask which one your team can absorb — and check how many of your dependencies are actively maintained, because that is where upgrades actually stall.
Hiring pool in your market, not globally
In many markets the React pool is much deeper. In others there is a strong Flutter community. This is a local question with a local answer.
Does the web app share code?
React Native plus React web shares types, validation, API clients and business logic. Flutter web exists but rarely serves a content-and-marketing site well.
The evaluation to run instead
One week, both frameworks, your product. It settles the question far better than any published comparison.
Build the same screen in both — your hardest one
Not a to-do list. The screen with the complex list, the custom control, or the chart. Two days each.
Integrate your single riskiest native dependency
The vendor SDK, the payment terminal, the BLE device. This is where projects actually get stuck, and it is cheap to find out now.
Measure on the worst device you support, not your own
A mid-range Android from three years ago. Both frameworks are fine on a current iPhone; the differences appear at the bottom of your device matrix.
Record cold start, scroll jank and install size
Same device, same build mode, same network. Write the conditions down beside each number or it is not comparable later.
Have the team that will maintain it do the building
Developer velocity is a property of the team, not of the framework, and it is the input that most affects the outcome.
A default, stated plainly
For a product with an existing React web team, a design system to honour, and ordinary native needs — camera, notifications, location, offline storage — React Native is our default, because the shared language and shared people are a real and continuing advantage.
We reach for Flutter when the UI must be pixel-identical across platforms and heavily custom, when there is no JavaScript team to leverage, or when the product is graphically rich in a way that benefits from owning the rendering pipeline outright.
Start here
Tell us what you are building
Or what is breaking, or what has to go faster. You will get a straight answer from an engineer who would do the work.