Flutter or React Native, and when to go native

Every mobile engagement starts here, and the argument is usually less consequential than it feels. Both frameworks ship real production apps at scale. The decision that actually matters is cross-platform versus native, and that one has a clearer answer.

The short version

Flutter draws its own UI with its own rendering engine. You get pixel-identical output on both platforms and excellent control over animation, at the cost of not automatically inheriting platform-native widget behaviour.

React Native maps your components to actual native views. You inherit platform behaviour for free and share code and skills with a React web team, at the cost of a bridge between JavaScript and native that occasionally matters.

Pick Flutter when

• The interface is custom and brand-led rather than following platform conventions
• Animation and visual fidelity are central to the product
• You want the two platforms to look and behave identically
• You are starting fresh with no existing JavaScript codebase
• The team is comfortable learning Dart, which takes an experienced developer a couple of weeks

Pick React Native when

• You already have a React web team and want shared skills and code
• The app should feel conventionally native on each platform
• You depend on a library that exists in the JavaScript ecosystem and not elsewhere
• You want over-the-air updates for JavaScript changes, which speeds up fixes considerably

When two codebases are worth it

Cross-platform is the right default for most apps. Go native when one of these applies:

Deep platform capability. Widgets, Live Activities, App Clips, Wear OS or watchOS companions, CarPlay or Android Auto, advanced camera control, background processing that fights aggressive battery management. Cross-platform can reach some of this through native modules, but if most of your app is that work, you are writing native code with extra steps.

Sustained heavy computation or graphics. Real-time video processing, on-device machine learning at high frame rates, complex 3D. The bridge cost stops being theoretical.

One platform dominates your revenue. If iOS is 90 percent of revenue, the argument for sharing code with an Android app almost nobody uses is weak.

Regulatory or SDK constraints. Some financial and healthcare SDKs ship native-only, with no maintained wrapper.

What actually decides it in practice

In most engagements the deciding factor is not technical. It is who will maintain the app in two years.

A team of React developers will move faster and produce better results in React Native than in Flutter, even where Flutter is marginally the better technical fit. A team with no JavaScript history will do fine with Flutter. Handing a team a stack they cannot maintain is a cost you pay every month afterwards.

The costs people forget

Store review is not instant. Budget days, not hours, and more for a first submission or a regulated category.

Platform releases force work whether or not you ship features. A new OS version, a deprecated SDK or a store policy change all force updates. An app with no maintenance budget will break.

Device fragmentation is an Android reality. Test on a mid-range device that is three or four years old, because that is what a large share of your users in India, Southeast Asia and much of the Gulf are actually holding.

Offline behaviour is where most mobile apps are weakest, and it is not a framework question. It is an architecture question you should answer before writing any UI.

A reasonable default

Start cross-platform unless you have a specific reason not to, and write the reason down. Reach into native modules where a platform capability requires it. Reconsider only if the native surface grows large enough that you are effectively maintaining two apps anyway.

---

We build in Flutter, React Native, Kotlin and Swift, and we make this call during discovery with the trade-offs written down. See our mobile services, or tell us about your app.