React Native vs Native: How to Choose a Stack for Your App

This question usually arrives already framed as a contest, with one side cheaper and one side better. It is not that. Cross-platform and native are two ways of paying for the same outcome, and which one is cheaper depends entirely on what your app has to do.

The decision is also less permanent than it sounds. Most serious cross-platform apps contain some native code, and most native apps share a backend. The real question is where you want the seam.

What the options actually are

Three approaches cover nearly every project worth discussing.

Native means Swift for iOS and Kotlin for Android: two codebases, each written in the language the platform was designed around, with immediate access to everything the platform offers.

Cross-platform means one codebase producing both apps. React Native and Flutter dominate here. Both produce genuinely native interface components rather than a website in a shell, which is the distinction that matters.

And then there is the web app wearing an app costume - a site wrapped in a native container. It is the cheapest option and occasionally the right one, but it feels like what it is, and app store reviewers have opinions about apps that are only a wrapper.

What one codebase actually saves

The headline claim is that you build once instead of twice. That is roughly true of feature code and misleading as a whole-project figure.

Business logic, screens, navigation and state are written once. That is a large share of most apps and a real saving. But testing still happens twice, because the platforms behave differently. Store submission happens twice. Platform-specific behaviour - permissions, notifications, background execution, deep links - needs attention on each side regardless of how much code is shared.

The bigger saving is not the initial build at all. It is every change afterwards. One team, one codebase, one fix means the two apps do not slowly diverge, which is what happens when two separate teams maintain what is nominally the same product.

The saving from one codebase is mostly collected after launch, not during the build.

What one codebase costs you

Cross-platform is not free, and the costs are specific rather than vague.

• A dependency on a framework you do not control, and on its release cycle.
• A short lag after major iOS and Android releases before new platform features are available to you.
• Reliance on third-party packages to reach some native capabilities, with the maintenance risk that implies.
• A ceiling on the most demanding graphics and animation work, which native clears more easily.
• The occasional problem that can only be solved by dropping into native code, which requires someone who can.

None of these disqualify it. Plenty of large, well-known products run on React Native. But a team that tells you cross-platform has no trade-offs has either not hit them or is not mentioning them.

When native is the right call

Some apps are pushed toward native by what they do rather than by preference. The pattern is consistent: the closer your core feature sits to the hardware or the operating system, the stronger the case.

Most apps are in the last two rows. The ones in the first four know who they are.

React Native or Flutter

If cross-platform is right, the choice between the two is usually less consequential than it is made to sound. Both are mature, both produce good apps, and both will be a reasonable decision in three years.

React Native uses JavaScript and TypeScript, which means it shares a language and often libraries with your web front end, and a larger pool of developers who already know it. Flutter uses Dart and renders its own widgets, which gives tighter control over pixel-identical interfaces across platforms and strong animation performance.

The practical tiebreaker is rarely technical. It is which one your team, or the team you are hiring, has actually shipped with. A framework nobody in the room has used in anger is the wrong choice regardless of its merits.

The warning sign in this conversation

Be cautious of any team that answers the stack question before hearing what the app does. "We build everything in X" is a description of the supplier, not a recommendation for you.

The answer you want sounds like a trade: this suits your case because of these specific requirements, here is what you give up, and here is the point at which we would advise otherwise. A team that can name the downside of its own recommendation has actually made a decision.

Our own position is that the stack follows the project - one codebase in React Native, or Swift and Kotlin where the platform demands it, which is how we run mobile app builds.

What matters more than the stack

It is worth saying plainly: for most products, the choice between React Native and native has less effect on the outcome than the quality of the people making it.

A well-structured React Native app maintained by people who understand both platforms will outlive a native app written carelessly, and vice versa. Architecture, testing and whether anyone is holding the design of the system in their head decide how the app ages. The framework mostly decides what is easy on day one.

How that ageing actually happens, and what it costs, is the subject of our post on technical debt.

So ask the stack question, insist on a reasoned answer, and then spend most of your attention on who is writing the code rather than on what they are writing it in.

For examples of what we have built and what each one runs on, see our portfolio.

Frequently asked questions