Native or cross-platform? Choosing a mobile stack you won't regret

React Native and Flutter are good enough for the overwhelming majority of apps. Which makes the only interesting question the one nobody asks: how do you tell, before you commit, whether yours is one of the exceptions?

The native-versus-cross-platform argument is usually conducted between engineers who have already decided. Here is the version we actually use with clients, which is about your product and your maintenance budget rather than anyone's preference.

What cross-platform genuinely buys you

One codebase, two platforms. In practice that means roughly 60–75% cost reduction versus building twice — not the 50% you might assume, because platform-specific work never disappears entirely.

The larger benefit is ongoing. Every future feature is built once, tested once and released once. Over three years of active development, that compounds into considerably more than the initial saving. It also means iOS and Android stay in step, rather than one quietly falling a version behind because that team was busy.

When cross-platform is the obvious answer

• Content, commerce and CRUD: if your app lists things, shows things, and lets people submit things, there is no meaningful argument for native.
• Internal and B2B tools: your users care that it works, not that it feels perfectly idiomatic.
• A small team: maintaining two native codebases with three engineers means both get under-maintained.
• An unproven idea: spending twice to validate something is a bad trade at any stage.

When native genuinely earns its cost

There are real cases, and they are more specific than “we want the best performance”.

• Sustained hardware access: continuous camera processing, Bluetooth peripherals, background location, ARKit. The bridge becomes the bottleneck and the workarounds cost more than native would have.
• Heavy graphics: games, real-time rendering, complex canvas work.
• Platform-first experiences: widgets, watch apps, deep Siri or Live Activity integration — where the OS integration is the product.
• Extreme size or battery constraints: the runtime overhead is real, and occasionally it matters.
• A large existing native team: the best stack is frequently the one your engineers already know well.

React Native or Flutter

If your team writes JavaScript or TypeScript, React Native is the lower-friction choice: shared language, shared libraries, often shared code with your web front-end, and hiring is easier almost everywhere.

Flutter gives more consistent rendering across devices and generally smoother animation, because it draws its own widgets rather than mapping to platform ones. The cost is Dart, a smaller hiring pool, and the fact that your app will look like your app rather than like the platform — which is a feature for some brands and a problem for others.

Both are mature and well supported. Choosing badly between them is far less costly than choosing badly between cross-platform and native.

The question that settles it

Ask what your app does in its most demanding thirty seconds. If that is scrolling a list, submitting a form or playing a video, cross-platform is correct and the conversation is over.

If it is processing a camera feed frame by frame, holding a Bluetooth connection while backgrounded, or rendering a complex scene at sixty frames per second, price the native version. Everything in between is a judgement call, and the honest answer is that it will not be the thing that decides whether your app succeeds.

The decision that matters more

Stack choice is not usually what sinks mobile projects. Store release is. First submissions get rejected for privacy declarations, missing account deletion, unclear permission prompts and demo credentials that do not work — and each rejection round costs a week.

Budget for release the way you budget for build, whichever stack you choose. It is the part of mobile work that most quotes ignore and most timelines discover late.