React Native vs Flutter

This is the difference that actually matters, so it is worth being precise. React Native takes the component tree you describe in React and realises it as the platform’s own native views. When you render a list, the operating system’s list implementation scrolls it. When you render a text input, it is the platform’s text input, with the platform’s keyboard behaviour, the platform’s text selection, the platform’s spell checking and the platform’s accessibility support already attached. Flutter takes a different route: it ships a rendering engine inside the app, asks the platform for a surface, and paints every pixel of the interface itself. The widgets you compose are Flutter’s, not the operating system’s.

The consequences run in both directions and they are consistent. Because React Native uses real platform controls, an app inherits an enormous amount of correct behaviour that nobody has to write or maintain: overscroll physics that feel right on each platform, date and time pickers users already recognise, share sheets, keyboard avoidance, dynamic type, right-to-left handling and the accessibility semantics that assistive technology expects. The price is that the same code produces results that differ between platforms, sometimes in ways your designers will file as bugs, and that heavily bespoke interfaces mean bending native components into shapes they were not designed for.

Because Flutter draws its own widgets, it produces identical output everywhere, and it can produce any output at all. There is no negotiation with a platform control that refuses to be styled, no per-platform divergence to reconcile, and no ceiling on what a custom component can look like. The price is that every piece of behaviour the platform would have given you is now the framework’s responsibility to reimplement. Flutter does this well, and the gap between a Cupertino widget and the real thing is small and closing. But it is a gap that has to be maintained by somebody, and when a platform changes a convention, Flutter has to catch up rather than simply inherit the change.

A practical way to decide: look at the design work you have already done. If the mock-ups are drawn once and the expectation is that both platforms match them exactly, you are describing Flutter. If the mock-ups assume platform conventions, use system components, and treat iOS and Android as having their own idioms, you are describing React Native. Choosing the framework that disagrees with your design process is how teams end up spending their budget reproducing behaviour that the other choice would have given them free.

We should say this plainly, because most comparisons will not. For the large majority of teams, the deciding factor in this choice is not the rendering architecture, the animation performance or the package ecosystem. It is what the people who will build and then maintain the app already know how to write. That is not an intellectually satisfying answer, but it is the correct one, and pretending otherwise leads teams to choose on a criterion that will never actually affect them.

React Native is React. Components, hooks, props, state, the same data-flow model, and TypeScript throughout. A web React developer reading a React Native codebase understands its shape immediately, and their first useful contribution is measured in days. More than that, a real portion of the code is not visual at all: validation rules, formatting, currency and date handling, API clients, error mapping, permission logic, analytics wrappers, design tokens. That layer can be shared or at minimum copied without translation, so a single team can own a web product and a mobile product without maintaining two versions of the same business rules in two languages.

Flutter is Dart, and nobody arrives already knowing it. This is a smaller obstacle than it sounds, because Dart is a clean, strongly typed, thoroughly conventional language and a competent engineer is productive in it quickly. But it is not zero. The learning curve is real, the hiring pool is genuinely smaller, the code shares nothing with a web front end written in anything else, and handover to a client team means handing them a language they may not otherwise use. If you can absorb that, Flutter has real compensating advantages. If you cannot, no architectural elegance makes up for it.

There is a corollary worth stating, because it cuts the other way. If your team has no React skills to preserve, the strongest argument for React Native disappears and the comparison becomes much closer, at which point Flutter’s coherence and its UI control start to look decisive. Native mobile teams in particular frequently prefer Flutter, because they were never going to reuse a web React codebase, they are used to a strongly typed compiled language, and Dart feels closer to Kotlin and Swift than JavaScript does. Choose on the skills you actually have, not the ones a comparison page assumes.

Both frameworks perform well enough that a user cannot tell your mainstream app from a native one, and most of the performance argument on the internet is about problems that were fixed or about workloads that neither framework should be used for. It is still worth understanding how each one fails, because the failure modes are different and each has a discipline attached.

React Native runs your application logic in a JavaScript engine and drives native views from it. Historically that communication crossed an asynchronous bridge that serialised every message, which is where the reputation for animation jank came from. The New Architecture largely removes that: JSI lets JavaScript hold direct references to native objects, the Fabric renderer sits on top of it, and TurboModules load native modules lazily without the old serialisation cost. What remains is a discipline rather than a defect. Keep the JavaScript thread free, run animations through the native driver or Reanimated so they are not at the mercy of it, virtualise long lists, and do not do heavy computation in JavaScript. Follow those rules and performance is a non-issue. Ignore them and you will produce a janky app, which is exactly what a great many of React Native’s critics have done.

Flutter compiles Dart ahead of time to native machine code for release builds, and the engine owns the frame directly, so there is no cross-language boundary in the render path at all. That is a genuinely good architecture for animation-heavy interfaces and it shows in practice. Its characteristic problems are different: rebuilding too large a slice of the widget tree on every state change, expensive work performed during a build, oversized images, and the additional cost of the first frame after a cold launch, since the engine has to start before anything is drawn. Binaries are also larger, because the app carries its own rendering engine.

The honest summary is that this axis should rarely decide the choice. Where it genuinely does is at the extremes. Interfaces built around continuous custom motion favour Flutter, because the render path is shorter and the tooling is built around it. Apps where install size and cold-start time are competitive concerns, or where the heavy lifting is native SDK work with a thin interface over it, favour React Native. Anything in the middle, which is most products, will be decided by the skills and design arguments above, and should be.

Every cross-platform project eventually needs something the framework does not provide: a payment SDK, a hardware feature, a partner’s native library, a background capability, an OS feature announced this year that your product roadmap depends on. How each framework handles that boundary is a practical difference that shows up repeatedly over an app’s life, and it is worth planning for rather than discovering.

React Native tends to reach new platform capabilities faster, for a structural reason. Because it already renders native views and already calls native code, exposing a new API is usually a matter of writing a thin native module in Swift or Kotlin and surfacing it to JavaScript. There is nothing for the framework itself to model first. Under the New Architecture those calls are direct rather than serialised across a bridge, which makes the boundary cheaper as well as simpler. The community consequence is that when a platform ships something new, a usable React Native wrapper often appears quickly, and if it does not, writing one yourself is a contained piece of work.

Flutter reaches the same capabilities through platform channels: you pass messages between Dart and native code, or you use a plugin that does it for you. This is well documented, thoroughly supported, and no barrier to a team that has done it before. Where Flutter is structurally slower to catch up is new platform user interface conventions, because a new system control cannot simply be adopted, it has to be redrawn by the framework. If your product must present the newest platform UI on the day it ships, that is a real consideration.

The advice for either framework is the same and worth taking seriously. Decide early where the line between framework code and native code falls, put a clean interface in front of it, and keep the native glue contained rather than smeared through the interface layer. Both frameworks let you reach anything the platform offers. Both punish projects that reach for native code accidentally, repeatedly and without a design, because every native dependency you add is a future upgrade you have signed up to manage.

The demo is not the product. What decides whether a mobile codebase is a pleasure or a millstone two years in is upgrades, dependency health and how much of the build pipeline you personally have to keep alive, and the two frameworks have different characters here.

React Native’s tooling has improved substantially, mostly because of Expo. The managed workflow, EAS Build and EAS Update remove the native toolchain setup, cloud builds remove an entire class of works-on-my-machine problems, and over-the-air updates let you ship JavaScript fixes to installed apps within hours instead of waiting for a review. The old objection that using native code meant ejecting has largely gone, since config plugins and development builds let you add native dependencies while staying in the managed flow. The honest caveat is that React Native version upgrades can still be genuinely painful, especially on projects carrying a pile of third-party native dependencies, and the New Architecture migration left some older libraries behind. Projects that let upgrades slide are the ones where this becomes a rewrite.

Flutter’s advantage is coherence. The framework, the language, the build system, the package repository, the test runner and DevTools come from one organisation and are versioned together, so there is less of a matrix of independently maintained pieces to keep compatible. Upgrades are generally less eventful, and pub.dev packages are on average better maintained than the equivalent React Native libraries because the ecosystem is smaller and more curated. Set against that, there is no equivalent of over-the-air code updates, so every fix goes through store review, and the smaller ecosystem means you will occasionally find that the wrapper you need does not exist and you are writing platform channels yourself.

One more thing that gets left out of framework comparisons and should not be: whoever inherits this codebase has to be able to work in it. If your client, or your own future team, writes React and TypeScript everywhere else, handing them a Dart codebase creates an island that only some people can maintain. If they are a native mobile team with no web front end in the picture, the opposite argument applies. Choose the framework that the people who will still be here in two years can actually own, because that decision outlives every technical argument on this page.

Start from the least comfortable fact: there is no migration path between these two in any meaningful sense. They share no language, no component model, no layout system, no state management and no build pipeline. Moving from one to the other means rewriting the entire application layer of your product in another language. Anyone describing it as a port is describing something else.

What does survive is worth naming, because it is more than teams expect and it changes the estimate. Your backend, your API contracts and your data model are untouched. Your designs, your design system specification and your product decisions carry across. Your understanding of the domain, the edge cases you discovered the hard way, your analytics events, your test scenarios and your store listings all survive. So does the release process, the certificates, the provisioning and the review experience. What has to be rebuilt is the user interface, the navigation, the state management, the client-side business logic and every native integration, which is to say the majority of the code but a smaller share of the accumulated knowledge.

If you must move, do it incrementally rather than as a big-bang rewrite. Both frameworks support being embedded inside an existing native application, React Native by mounting a view into a native screen and Flutter through its add-to-app support. That gives you a route where a native shell hosts the old framework and the new one side by side, and screens move across one at a time in shipped releases rather than in a branch that lives for eight months. It is fiddly, it costs more per screen than a clean rewrite would in theory, and it is still almost always the right call, because it keeps the product shipping and lets you stop halfway if the new framework turns out not to solve your problem.

The honest advice, though, is usually not to do it at all. We are regularly asked to move working apps between these frameworks, and the stated reason is almost always a symptom rather than a cause: performance problems that are actually an unvirtualised list or an over-broad rebuild, a codebase nobody can work in that is really an architecture problem, or a hiring difficulty that a framework change would not solve. Diagnose the actual complaint first. If the app is slow, profile it, because both frameworks are capable of a smooth mainstream app and the fix is usually specific and cheap. If the real problem is that your team writes React and the app is in Dart, or the reverse, then the case for a rewrite is a business case about who can maintain the product, and it should be argued and costed as one rather than dressed up as a technical necessity.