The native-versus-cross-platform question gets asked at the start of almost every mobile engagement we take on. The honest answer — which is unsatisfying but correct — is that it depends. But the factors it depends on are more specific than most articles acknowledge, and the tradeoffs have shifted meaningfully over the past two years.
Here is our current position, based on the products we have actually shipped.
When React Native is the right call
React Native is a good fit when two or more of the following are true.
You already have a React web frontend. Shared business logic, type definitions, and some utility code between your web and mobile product is a genuine, compounding advantage. It keeps behaviour consistent across platforms, reduces duplication, and means engineers can contribute across the stack. This is not a theoretical benefit — it is one we see on almost every engagement where both surfaces exist.
The UI follows platform conventions. Apps that use standard navigation patterns, standard list views, and standard form controls work well in React Native. The bridge to native APIs is smooth for conventional UI work. Custom interactions — complex gesture recognisers, unusual navigation paradigms, heavily animated interfaces — are where the friction shows.
Your team needs to move fast in the early stages. React Native’s hot reload, its shared ecosystem with the web, and the ability to have one engineer contribute to both platforms meaningfully shortens early iteration cycles. When proving the product is the goal, this matters more than it will later.
You cannot justify two separate codebases. Maintaining a native iOS and a native Android codebase is two distinct engineering efforts with different tooling, different debugging workflows, and different release processes. For most early-stage products, that overhead is not justified by the marginal experience improvement.
When native is the right call
The app’s core value is performance. Games, camera-heavy applications, real-time audio or video processing, anything that does significant on-device computation — the gap between native and cross-platform is felt by users in these categories. React Native’s performance story has improved substantially with the new architecture, but the ceiling is lower and the floor requires more careful management.
You need deep platform integration. Bluetooth peripheral communication, custom keyboard extensions, App Clips, home screen widgets, Apple Watch connectivity, CarPlay — anything at the edge of what the platform SDK exposes is substantially easier to build and maintain natively. The React Native community often has libraries for these, but they lag behind OS releases and are frequently unmaintained.
You are building for users who notice. A small but vocal minority of users can identify cross-platform apps. They are overrepresented in App Store reviews. For consumer apps where App Store perception is commercially significant, the reputational risk of being identified as a “React Native app” is worth factoring in. This matters far less for B2B products, where the users care about what the app does, not what it is built with.
A word on Flutter
Flutter deserves a direct mention because it is often the third option clients arrive with. For greenfield cross-platform work where you do not have a React web frontend and are not constrained by an existing team’s skills, Flutter is a serious option. The performance story is better than React Native for custom UI — the rendering engine bypasses the native UI layer entirely, which removes a category of inconsistency. The developer experience is strong. The ecosystem has matured considerably.
It is worth evaluating on those terms rather than dismissed by default. If there is no existing web frontend and no team constraints pulling toward React, Flutter deserves a real look alongside React Native — the right choice follows from the project’s constraints, not from a shop’s default stack.
The practical answer
For most B2B SaaS mobile apps, React Native is enough. The experience is good, the development is faster, and the cross-platform maintenance savings are real.
For most consumer apps with standard UI patterns, React Native is also enough. The polish gap between a well-built React Native app and a native app is smaller than it was two years ago and continues to close.
For apps where the native feel is the product — where performance, custom UI, or deep platform integration is the core of the experience — go native. The additional cost is real, but so is the difference.
If you are not sure which category you are in, that is what the discovery week is for. The answer is usually clearer than it seems once you have written down what the app actually needs to do.