8 min read
Native or React Native: how to actually decide
Swift and Kotlin or one React Native codebase? The decision rules that hold up after the build, not the ones that win the pitch.
Every mobile project starts with this argument, and most teams settle it on the wrong axis: cost. Cost is an output of the decision, not an input to it. The input is what your product does with the device it runs on.
What React Native is actually good at
React Native shares one TypeScript codebase across both stores. Where the interface is lists, forms, navigation and content — commerce, booking, dashboards, internal tools — that sharing is close to free, and you get two platforms for roughly one budget.
- Shared product logic, shared state, shared API layer
- Over-the-air updates for anything that doesn't need store review
- One team, one hiring profile, one review cycle for most changes
Where it stops being cheaper
The saving erodes wherever the product touches the device rather than the screen. Continuous sensors, complex gesture-driven animation, widgets, watch apps, background processing and on-device inference all end up as native modules — written in Swift and Kotlin, twice, by people who know both.
The decision rule
Ask what a user would notice if you got it wrong. If the answer involves feel — latency, gesture, animation, responsiveness under load — build native. If the answer involves features and content, React Native is the cheaper build and the honest choice.
What we do
We reach for React Native deliberately, not reflexively, and default to native iOS and Kotlin when the product lives on the device. Either way the reasoning goes in the written scope, so the decision can be audited a year later instead of relitigated.