React Native or native? What actually matters for your app
Native means writing your app twice — Swift for iOS, Kotlin for Android. Cross-platform means one codebase producing both. The trade-off is narrower than it was five years ago.
The real cost of two codebases
Two codebases is not just double the build. It is double the bug fixes, double the release cycles, and a permanent risk of the platforms drifting apart in behaviour. Over three years, maintenance usually costs more than the original build.
When cross-platform is clearly right
Business applications, marketplaces, booking systems, internal tools, content apps — anything where the app is mostly screens, forms, lists and API calls. React Native handles these without compromise, and your users will not be able to tell.
When native is worth the extra cost
- Graphics-heavy applications and games
- Sustained background processing — continuous location tracking, audio, sensor capture
- Early adoption of brand-new OS features
- Apps where a few milliseconds of interface latency is a competitive issue
What people get wrong
The usual objection is performance, and for the vast majority of business apps it is no longer a real constraint. The genuine constraint is native modules: if you need a device capability with no maintained bridge, someone has to write native code anyway.
That is worth checking during scoping rather than discovering in week six.
A reasonable default
Start cross-platform unless something on the native list applies. If you later need one screen to be native, React Native lets you write that screen natively without rewriting the app.