React Native or native: how we decide
The framework argument is usually the wrong argument. What matters is whether the product depends on platform depth, and who maintains it in a year.
Almost every mobile conversation opens with a framework question, and almost none of them should. The decision is downstream of two things: how much the product depends on platform capability, and how many people will be maintaining it twelve months from now.
We reach for React Native for roughly three quarters of products. The reason is parity economics — one codebase means iOS and Android ship the same feature on the same day, and a team of four can sustain that. Two native codebases means two specialists and a permanent risk that one of them leaves.
We go native when the product's value is a platform capability. Sustained background processing, heavy media pipelines, complex camera or sensor work, deep widget and watch integration. In those cases the bridge is not the problem; the problem is that you spend the project fighting for access to the thing the product is about.
The performance argument is mostly settled and mostly misused. With the new architecture and Hermes, list scrolling and animation are close enough that users do not notice. What users do notice is cold start time, and that is an engineering discipline rather than a framework property.
The question we actually ask clients is this: in a year, is this app maintained by a mobile team or by your existing web engineers with help? If it is the latter, a shared TypeScript codebase is not a compromise, it is the only version that survives.