There is no correct answer to "React Native or native?" — only a correct answer for your product. Here are the four questions we ask, in the order we ask them.
1. Does the product live or die on a platform capability?
If your app's reason to exist is a Bluetooth protocol, real-time video processing, ARKit, a custom camera pipeline, or background audio with unusual behaviour, go native. Cross-platform frameworks can reach these things through bridges, but you will spend your time in the bridge rather than in your product.
If your app is screens, forms, lists, media, notifications, and an API — which describes the overwhelming majority of apps — cross-platform is not a compromise. It is just the cheaper way to get the same result.
2. How different are the two platforms allowed to look?
Some products need to feel unmistakably like an iOS app on iOS and an Android app on Android. Banking, system utilities, and anything competing with a first-party app usually fall here.
Most consumer and business apps do not. They have a brand, and the brand is the interface. If your designer is drawing one set of screens rather than two, that is your answer.
3. What team will maintain this in two years?
This is the question people skip and then regret. If you will have one developer, cross-platform means one codebase they can hold in their head. If you already employ Swift and Kotlin engineers, native means they stay productive.
Do not pick a stack your future team cannot hire for.
4. How fast do you need the second platform?
Cross-platform's real advantage is not total cost — it is simultaneity. Two stores on the same day, with the same features, from one team. If your launch plan is iOS now and Android maybe next year, that advantage is worth much less, and the calculation shifts.
What we usually recommend
For a first release from a startup, React Native with Expo, most of the time. It gets you to both stores quickly, the ecosystem is mature, and over-the-air updates mean a bug fix does not wait on review.
We recommend native when question one says so, and we say it plainly rather than stretching a framework past what it does well.
The part nobody argues about
Whatever you choose, the things that decide whether your app succeeds are the same: cold start time, offline behaviour, how errors are handled, and whether you can ship an update without drama. We have seen sluggish native apps and snappy cross-platform ones. The framework sets the ceiling; the engineering decides where you land under it.