The React Native versus native debate has been running for years and the takes have not gotten more nuanced. React Native fans say it is good enough for almost everything. Native purists say performance and platform feel are non-negotiable. Both are right in some contexts and wrong in others.
Here is how we actually make this decision with founders.
The questions that determine the answer
Before we discuss frameworks, we ask four questions:
- How important is native platform feel? A fintech app used daily by professionals has different expectations than a B2C consumer app used weekly.
- Do you need platform-specific features? Deep camera control, background processing, widgets, CarPlay integration — these are easier to build natively.
- What is your team's current skill set? The best stack is the one your team can move fast with.
- What is your timeline and budget? Cross-platform means one codebase, which usually means faster development and lower maintenance cost.
The right answer is almost never about the framework. It is about the constraints of your specific situation.
When we recommend React Native
Your app is primarily UI-driven. Forms, lists, feeds, dashboards, e-commerce flows — React Native handles all of these well and the performance difference from native is imperceptible to most users.
You are building for both iOS and Android. Maintaining two separate codebases doubles your QA surface, your build pipeline complexity, and your cost. For most products, the tradeoff is not worth it.
Your team knows JavaScript. The talent pool for React Native is significantly larger than for Swift or Kotlin. Hiring is easier, handoffs are smoother, and future developers are easier to find.
Speed to market matters more than perfection. For an MVP or a seed-stage product, getting something in users' hands quickly and iterating beats spending six months building the perfect native experience.
When we recommend going native
You need hardware access that React Native cannot abstract cleanly. Real-time audio processing, advanced camera pipelines, Bluetooth LE, NFC — anything that needs to talk directly to device hardware benefits from native.
Your app has demanding animation requirements. Games, anything with 60fps complex animations, or apps that depend on the platform's native gesture system working exactly right. React Native has improved massively here but there is still a gap at the edges.
You are building for one platform only. If you are iOS-only (common in certain enterprise and premium consumer categories), there is no cross-platform benefit to weigh against the tradeoffs.
Your users are power users with high standards. Professional tools used for hours a day by people who know their platform well. They will notice subtle differences in scroll momentum, keyboard behaviour, and system integration.
For most early-stage products: React Native with Expo. Ship fast, validate, then optimise where performance actually matters — which is almost never everywhere.
The Expo question
If you go React Native, should you use Expo? Almost always yes, especially at the start. Expo handles the build tooling, over-the-air updates, and a massive library of pre-built modules. The cases where you need to eject are real but rare.
The main reasons to skip Expo: you need a native module that does not exist in the ecosystem, or you need very fine-grained control over the build output. Otherwise, the productivity benefit outweighs the constraints.
What we have shipped and what we learned
We have shipped React Native apps in fintech, health, and logistics. In every case, the client wanted native feel and in every case, end users could not distinguish the difference in usability tests. Performance was not the bottleneck — product decisions were.
We have also shipped native iOS for a professional photography tool where camera pipeline control was genuinely non-negotiable. The right call there. But that is the exception, not the rule.
Most apps do not need the last 5% of platform performance. They need to be in users' hands in three months, not six.
The honest conclusion
Start cross-platform unless you have a specific reason not to. Build the product. Talk to users. When you have evidence that performance or platform integration is causing real user problems — not hypothetical ones — optimise then. Almost no early-stage product ever reaches that point.
Building a mobile app? Let's figure out the right approach together.