React Native builds iOS and Android apps using React. Unlike Flutter it uses each platform's real native controls, so the app feels native on both. Its biggest advantage is organisational: a React web team can build and maintain it.
What is React Native?
React Native takes the React programming model — components, state, the same mental model as the web — and renders it to real iOS and Android controls rather than to HTML. A React Native button is an actual UIButton on iOS and an actual Button on Android.
That produces an app that feels correct on each platform, because it is using each platform's own components, and it means platform conventions like scroll physics and text selection behave the way users expect without anyone implementing them.
Meta built it for their own apps and still uses it, which matters for the same reason it matters with React: the hard problems have been found at a scale we will not reach.
When we choose React Native
When the client already has React developers. The app becomes something the existing team can contribute to rather than a separate discipline requiring a separate hire, and that changes the long-term cost of ownership more than any technical difference.
When validation rules, pricing logic and API types can be shared between web and app. Written once, typed once, correct in both places by construction — this is the largest practical saving React Native offers.
And when the app should feel like the platform rather than like the brand. Native controls do that automatically.
When we do not use React Native
When the client has no React investment. Flutter is a more coherent package for a team starting fresh, with fewer configuration decisions and a more predictable build.
When the design demands a highly custom interface that ignores platform conventions. React Native fights that; Flutter is built for it.
And where heavy native work dominates — sustained video processing, complex graphics. The bridge between JavaScript and native has a cost, and at that end of the spectrum it shows.
What we build with React Native
Companion apps to a React web product
The mobile half of a product that already exists on the web, sharing types, validation and API layer with it. One change to a business rule updates both, which is the failure mode this avoids.
Internal staff apps
Stock counts, inspections, deliveries, approvals — tools used by staff rather than customers. Native feel matters less than shipping quickly and being maintainable by the team that already exists.
Companion apps to an existing web product
Where the web app already exists in React and the mobile app is the same product on a phone. Shared logic, shared types and one team means the app tracks the web product instead of falling behind it.
Apps that ship fixes without a store review
Over-the-air updates let a JavaScript-level fix reach users in hours rather than waiting on review. For a product still finding its shape, that changes how quickly you can respond to what users actually do.
How we ship React Native projects
On Expo unless there is a specific reason not to. It removes most of the native build configuration that makes React Native projects fragile, and its update mechanism lets a fix reach users without waiting for store review — which on iOS can be days.
Shared code lives in a typed package used by both web and app, rather than being copied. Copied logic is logic that will diverge.
What React Native costs you
Native build configuration is where React Native projects break, and upgrading across major versions has historically been painful. Expo removes most of that, and we use it for exactly that reason.
Because it uses each platform's real controls, small differences between iOS and Android surface in ways Flutter does not have — and reconciling them is real work that a cross-platform pitch tends to leave out.
Native modules are where the time goes. Anything the framework does not wrap — a specific payment SDK, a hardware peripheral, an unusual permission — means writing platform code twice, and that is exactly the work cross-platform was supposed to avoid.
Upgrades have historically been painful too, though considerably better than they were. Budget a day or two a year for keeping the framework current rather than letting it drift three versions behind.
React Native questions we get asked
Largely, yes — that is the main reason to choose React Native. They will need help with the native build setup and store submission, but the application code is React they already understand. We usually build the first version and hand it over with the team involved throughout.
React Native if your team already writes React and the web product shares logic with the app. Flutter otherwise — it is more consistent across platforms and generally smoother out of the box. Neither is a bad choice; the deciding factor is your existing team.
Yes, with the right libraries — animations run on the native thread rather than in JavaScript, so they stay smooth under load. Where it still struggles is very heavy list rendering and anything doing sustained work on the JavaScript side.
Mobile app development starts at $18,000 and typically runs $25,000–$60,000 over eight to sixteen weeks for both platforms. Building the same app natively twice is roughly 1.7 times that, which is the trade cross-platform exists to avoid.
If it is built for it, yes. Local storage with background sync means a driver in a basement car park or a technician on a site with no signal keeps working, and the data reconciles when the connection returns. This has to be designed in from the start — retrofitting offline support later is close to a rewrite.
Business logic, validation, types and API clients, yes — that is a genuine saving. Components, mostly no, because a phone screen is not a browser window and pretending otherwise produces an app that feels like a website. We share the logic deliberately and build the interface for the device.