React Native vs native
One codebase, or two that fit properly.
The cross-platform argument is usually made on cost — one codebase instead of two — and that saving is real but smaller than the pitch. Expect thirty to forty per cent rather than fifty, because the platform-specific work does not disappear, it just moves.
Start with the shape
of the problem.
The cross-platform argument is usually made on cost — one codebase instead of two — and that saving is real but smaller than the pitch. Expect thirty to forty per cent rather than fifty, because the platform-specific work does not disappear, it just moves.
The better question is what your app actually does. If it is screens over an API with conventional interactions, cross-platform is a straightforward win. If it leans on the camera, background processing, Bluetooth, sustained animation or platform-specific interface conventions, the bridge starts costing you the thing you bought it for.
We have shipped and maintained both, including one app we migrated from React Native to native and one we migrated the other way. Neither migration was caused by the framework being bad.
| Criterion | React Native | Native (Swift / Kotlin) | Edge |
|---|---|---|---|
| Build cost for a conventional app | One team, one codebase. Roughly 30–40% less than two native builds in our experience. | Two codebases, two skill sets, two release pipelines. Higher, and honestly so. | React Native |
| Performance ceiling | Excellent for list-and-form apps. Sustained 60fps animation and heavy graphics take real effort. | The ceiling is the device. Nothing sits between your code and the platform. | Native (Swift / Kotlin) |
| Access to new platform features | Waits for a library, or you write the native module yourself — which is native work with extra steps. | Available on day one of the OS release. | Native (Swift / Kotlin) |
| Platform interface conventions | Achievable, but "write once" produces an app that feels slightly foreign on both platforms unless you deliberately diverge. | Native components behave the way users already expect, including the accessibility behaviours. | Native (Swift / Kotlin) |
| Release and update speed | Over-the-air updates for JavaScript changes mean fixes ship without a review cycle. | Every change goes through store review, including one-line fixes. | React Native |
| Hiring and continuity | A large pool of React engineers can contribute, including your existing web team. | Two specialist hires, or two agencies, and both are scarcer and dearer. | React Native |
| Long-term maintenance | Upgrades across React Native versions and native dependencies are real, recurring work. | Predictable annual OS churn, well-documented, but doubled across two codebases. | Line ball |
| Accessibility | Good, provided somebody tests with VoiceOver and TalkBack. Defaults are weaker than native. | Strongest defaults, since platform components carry accessibility behaviour for free. | Native (Swift / Kotlin) |
- The app is primarily screens, forms and lists over an API
- You have React engineers already and want them contributing
- Both platforms need to launch together on a fixed budget
- Shipping fixes without waiting for store review has real value
- You are validating a product and want the second platform cheaply
- Camera, Bluetooth, background processing or sensors are central to the product
- Sustained animation, graphics or audio performance is part of the experience
- You need new OS features in the quarter they ship
- The app is a long-lived flagship where feel is a competitive advantage
- Accessibility conformance is contractual and you want the strongest defaults
Our honest
recommendation.
For most B2B products, internal tools and content-and-transaction apps, React Native is the sensible default, and the saving is best spent on the parts users actually notice: onboarding, empty states, offline behaviour and speed to first meaningful action.
Go native when the hardware is the product, when performance is the differentiator, or when the app is a flagship you will still be investing in five years from now. Also go native when you only need one platform — cross-platform tooling costs you complexity you are not using.
What we would avoid is choosing cross-platform to save money and then rebuilding half of it in native modules. If the feature list is already full of camera, Bluetooth and background work at the briefing stage, the saving is imaginary.
What teams ask next.
For the overwhelming majority of apps, yes — the bottleneck is almost always the network and the API, not the bridge. Where it strains is sustained animation, heavy list virtualisation with complex cells, and real-time graphics or audio. Those are worth prototyping before committing.
Thirty to forty per cent against two native builds, in our project history. Not fifty, because the platform-specific work — permissions, store metadata, notifications, deep links, device testing, accessibility passes — has to be done twice regardless of how much code is shared.
A strong option technically, and we have shipped with it. The practical arguments against it in a B2B context are hiring pool and the fact that your existing web engineers cannot contribute. If your team is already Dart-fluent, most of this comparison applies with the labels changed.
Yes, and it is a reasonable strategy if the API and the domain logic are cleanly separated from the interface layer from day one. The migration is a rewrite of the interface, not of the product, which is a much smaller thing than it sounds.
App development
iOS, Android and cross-platform apps shipped by a senior team that stays through the store review.
UI/UX design
Product-focused design: flows, states and interfaces judged on whether the job gets done.
QA & testing
Manual and automated coverage that finds the failure before your customers volunteer to.
API & third-party integrations
CRMs, ERPs, payments and internal tools connected so the data stops being re-typed by people.
Rather not decide in the abstract?
Send us the situation. We will tell you which we would choose in your position, including when that answer earns us less.