We stopped guessing at native vs cross-platform. Here is the actual decision tree
After 90+ shipped apps the answer is not "it depends" — it is four questions, in order, and the first one that answers yes decides it.
Marcus Chen
Head of Mobile
"Should we go native or cross-platform" is the most common question we get in discovery, and the most common answer in our industry is a shrug dressed up as nuance. After ninety-odd shipped apps, we do not think it is nuanced. It is four questions asked in order.
1. Does the app depend on a platform API that has no good bridge?
Background location with meaningful accuracy. HealthKit or Health Connect. Bluetooth peripherals with custom GATT services. Heavy real-time camera work — AR, ML on the frame buffer, custom capture pipelines. CarPlay or Android Auto. Widgets and complications that do real work.
If yes, go native. The bridge exists for most of these, and it will cost you more in debugging edge cases than the second codebase would have cost you to write.
2. Do you compete on feel?
Not "do you care about quality" — everyone says yes to that. Do your users choose you *over a competitor* partly because your app feels better? Consumer social, premium subscription products, anything where the app is the product rather than a channel to it.
If yes, go native. Cross-platform gets you to about 90% of native feel. That last 10% is scroll physics, keyboard behaviour, gesture interruption and transition timing, and in a competitive consumer category it is the whole game.
3. Is your team going to maintain this?
If you have one mobile engineer, or a web team who will inherit it, a React Native codebase they can actually work in beats a native pair they cannot. The best architecture is one that survives the people who own it.
4. Is the budget the binding constraint?
If you got here, the answer is Flutter or React Native, and it is not a compromise — it is the right call. One codebase, both stores, roughly 60% of the cost of two native builds.
Flutter or React Native, then
Flutter if the UI is custom and brand-heavy: it draws every pixel itself, so a designed interface looks identical on both platforms and complex animation is genuinely easier. Its weakness is that "identical on both platforms" is also a downside when users expect platform-native behaviour.
React Native if your team is already React, or you need deep native module work, or your UI is largely standard platform components. It uses real platform views, so a list feels like a platform list without you doing anything.
What we tell clients
We give this answer in writing during discovery with the reasoning attached, because the honest version of it sometimes costs us money — question 4 is a smaller project than question 1. We would rather lose the difference than build the wrong thing and spend the savings on the rewrite in year two.
