React Native works best on the app most companies actually need: accounts, lists, forms, search, notifications, payments. Two platforms, one team, one set of business rules to keep correct.
What it shares and what it does not
The screens, navigation, state and API layer are shared. Push registration, deep-link configuration, permissions, store metadata and anything touching a device API are still two platforms with two behaviours. We plan for that native work from the start instead of discovering it in the last sprint.
Reusing the web team’s knowledge
If your web product is React, the mental model transfers — components, hooks, the same TypeScript types for API responses. That shared vocabulary is often worth more than the shared code.
Performance, specifically
Long lists get proper list virtualisation, not a mapped array. Animations run on the native driver so they survive a busy JavaScript thread. Images are sized and cached. Startup time is measured on a mid-range Android device, because that is where a slow app becomes an uninstall.
Upgrades are a planned cost
React Native moves, and so do the libraries around it. We budget an upgrade window rather than letting a project sit three major versions behind until a mandatory store change forces a scramble.
When to go native instead
Heavy camera or media processing, complex background location, deep platform integration, or an interface that must feel unmistakably native on both sides: that is Swift and Kotlin territory, and we will tell you so before you commission the cheaper version.
Compare with Flutter or read mobile development.