React Native vs Native App Development: How to Choose
Shakewell ·
This decision gets made on the wrong grounds more often than almost any other in mobile. Teams choose native because it sounds more serious, or cross-platform because it sounds cheaper, and neither is a reason.
The useful question is narrower: what does your app actually do that touches the platform?
What each one is
Native means building twice — Swift for iOS, Kotlin for Android — against the platform’s own APIs. Full access to everything the device offers, on the day it ships.
React Native means one codebase in JavaScript or TypeScript rendering real native components on both platforms. Not a web view: the UI is genuinely native, with shared logic underneath.
The trade is not quality. Both produce apps that feel native. The trade is between platform reach and duplicated effort.
When React Native is the right answer
For most business apps, and here is the honest reason: you are not building two products, you are building one product twice.
It fits well when:
- The app is largely screens, forms, lists, accounts and API calls — which describes the majority of business apps
- You need both platforms and cannot justify two teams
- The roadmap changes often, and shipping a change once rather than twice compounds
- The value sits in the backend, with the app as the surface
That last point matters more than it sounds. The Sporting Club of Sydney members app is React Native, carrying digital wallet membership cards, QR gate entry and live gym busyness. Its hard problems are entitlement, wallet pass issuance and being correct on match day — none of which is a rendering problem, and all of which lives behind the app.
When you genuinely need native
Four cases, and they are narrower than they are usually claimed to be:
Heavy real-time graphics. Games, AR, live video processing. Anything where you are fighting for frames.
Deep or new platform hardware access. Specialised Bluetooth, advanced camera control, secure enclave work, or a platform capability released last week. React Native reaches most hardware through libraries, but “most” is doing work in that sentence — and being first to a new API means writing native anyway.
Sustained background processing. Continuous location tracking, background audio, long-running sync. Both platforms constrain this tightly and the controls are native.
A platform-specific product. If iOS and Android versions are genuinely different products rather than one product on two platforms, sharing a codebase creates friction rather than removing it.
The factor nobody weighs properly
Who maintains it in year three?
A React Native app can be maintained by developers who also work on your web front end. A native app needs Swift and Kotlin skills, indefinitely, for a codebase that ships a few times a year. For a business without an in-house mobile team, that is the difference between an app that stays current and one that quietly rots until it stops working on a new OS release.
Both platforms ship a major version annually. Whatever you choose, something has to be maintained twice a year — the question is whether that is one codebase or two.
The honest costs of React Native
Not a free lunch, and pretending otherwise is how projects get disappointed:
- A dependency layer you do not control. Native modules are third-party, and one can lag a platform release at exactly the wrong moment.
- Upgrades can be genuine work. React Native’s own major upgrades are usually straightforward and occasionally not.
- Some things still need native code. Expect to write or commission some, and budget for a developer who can.
- Debugging crosses a boundary. A problem can live in JavaScript, in the bridge, or in native code, and finding out which takes longer than in a single-language codebase.
The framework
Four questions, in order:
- Does the app do anything on the hardware beyond camera, location and notifications? If no, cross-platform is almost certainly right.
- Is there sustained background work or real-time graphics? If yes, look hard at native.
- Who maintains it, and do they already write JavaScript? This decides more real-world outcomes than the technical comparison does.
- Are iOS and Android the same product? If they diverge meaningfully, the shared codebase stops paying for itself.
What we recommend, and when we don’t
We build in React Native for most business apps because the maintenance economics are better and the result is genuinely native. We say native when the app is fighting for frames, needs deep hardware access, or must run work in the background continuously.
What we try not to do is let the decision be made on prestige. Native is not more professional; it is more appropriate in a narrow set of cases, and more expensive to own in all the others.
If you are weighing this for a specific build, we are happy to talk it through — the useful conversation is about what the app touches, not which technology sounds better.
Related: React Native development · App development · What a website costs in Australia