The mobile stack decision is usually argued on the wrong axis. It gets framed as a cost question — cross-platform means one codebase, so roughly half the work — and settled on that basis.

The cost argument is real but overstated, and it is not the factor that determines whether the choice was right. What determines that is how closely your app depends on the device itself.

Here is a framework that has held up well across the projects we have delivered.

The honest version of the cost argument

Cross-platform does not halve the work. Shared business logic, data handling, networking and much of the UI genuinely are written once. But a substantial portion of mobile effort is not in that layer: platform-specific design conventions, store submission and review for each platform, device-specific testing, permissions handling, push notification setup per platform, and the native modules you inevitably need for anything the framework does not wrap.

A realistic expectation is a meaningful saving over two fully separate native builds — enough to matter to a budget, not enough to treat the second platform as free. Teams that plan on the basis of “one codebase, one cost” are consistently surprised.

There is also a longer-term cost that rarely appears in the initial comparison: you inherit a dependency on the framework’s maintainers. When a new OS version lands with a breaking change, native apps can adopt immediately; cross-platform apps wait for the framework to catch up. This is usually weeks, occasionally longer, and it is a real constraint if your app must support new OS features on day one.

The question that actually decides it

How much does your app depend on the device, as opposed to depending on your servers?

Picture a spectrum. At one end, an app that is essentially a well-designed interface over an API — lists, forms, detail views, search, authentication, payments. Most business apps live here. At the other end, an app whose value comes from the hardware: sustained camera processing, real-time audio, Bluetooth peripherals, background location, augmented reality, tight platform integrations like widgets and watch apps.

The further towards the device end you sit, the more the case for native strengthens — not primarily for performance, but because that is where cross-platform abstractions leak. You end up writing native modules for both platforms anyway, and now you maintain those plus the bridge plus the shared layer. That is more complexity than either pure approach.

The options

Native (Swift / Kotlin)

Choose when: the app is device-heavy; you need new OS capabilities the day they ship; you require the highest possible standard of platform-idiomatic feel and accessibility; or the app is a long-lived core product where you want no dependency between you and the platform.

Accept: two codebases, two skill sets, two hiring pipelines, and features landing on one platform before the other unless you deliberately hold releases.

A note on accessibility: native has the advantage here, because the platform’s own accessibility APIs are used directly rather than through a translation layer. If accessibility is a compliance requirement rather than an aspiration, weigh this seriously and test with real assistive technology whichever route you take.

React Native

Choose when: your app sits towards the API-driven end of the spectrum, and — this is the decisive factor — you already have React developers.

That is the strongest argument for React Native and it is an organisational one. A web team fluent in React can become productive on mobile without hiring two new specialisms, share patterns and tooling across web and mobile, and move people between them. For a company already invested in React, this is a substantial and durable advantage.

Accept: a JavaScript dependency chain that needs active maintenance, occasional friction at the native boundary, and upgrades that require real effort rather than being routine.

Flutter

Choose when: you want strong cross-platform consistency and a highly controlled custom design language, and you have no existing React investment pulling you the other way. Because Flutter renders its own widgets rather than mapping to platform controls, you get very consistent output across devices and considerable design freedom.

Accept: Dart, which is a smaller talent pool than JavaScript and typically means training existing engineers rather than hiring ready-made. Also accept that rendering its own widgets is a double-edged property: consistency is easy, and matching each platform’s native conventions exactly takes deliberate work.

Factors that should not decide it

• Raw performance benchmarks. All three options are comfortably fast enough for typical business applications. Performance problems in real apps overwhelmingly come from network patterns, oversized images, and doing work on the main thread — not from the framework. Choosing a stack on benchmark numbers optimises something that is rarely the bottleneck.
• Which is most popular this year. All three have serious backing and healthy ecosystems. Popularity trends matter for hiring, and hiring is better assessed against your actual local market than against a global survey.
• What one influential engineer prefers. Preferences are useful data about what your team will maintain enthusiastically. They are not a substitute for the device-dependency analysis.

The cost nobody budgets: staying current

Mobile is unusual among software platforms in that standing still is not an option. Both major platforms release annually, both periodically raise the minimum SDK version required to ship an update to their stores, and both deprecate APIs on a schedule.

The practical consequence is that a mobile app requires ongoing engineering attention purely to remain publishable, even if you never add a feature. An app left untouched for two years will typically not build against current tooling, may no longer be accepted by the stores, and will have accumulated a dependency upgrade path that has to be walked in steps rather than jumped.

This cost lands differently across the three options. Native apps track platform changes directly — the work is regular and predictable. Cross-platform apps add a second layer: you wait for the framework to support the new platform version, then upgrade the framework, which periodically involves breaking changes across your own code and every third-party package you depend on.

Neither is worse in total, but the shape differs. Native is a steady trickle; cross-platform is quieter with occasional larger upgrade projects. Plan for whichever shape you choose, and treat “we will maintain it when we need to” as the decision to eventually pay much more.

One practical mitigation regardless of stack: keep your dependency count deliberately low. Every package added is a package that must survive each future upgrade, and abandoned packages are the most common reason a cross-platform upgrade turns into a rewrite.

A practical sequence

1. List every device capability the app needs — camera, Bluetooth, background location, biometrics, widgets, health data, offline sync, and so on. Be exhaustive, including roadmap items for the next 18 months.
2. Check each against your candidate frameworks. Is there a mature, maintained package, or would you write a native module? Count the native modules.
3. If the count is high, choose native. The abstraction is not buying you much and is costing you a bridge to maintain.
4. If the count is low, choose based on your team. React developers on staff points to React Native. No existing investment and a desire for a distinctive controlled design system points to Flutter.
5. Prototype the single riskiest feature before committing. One week spent proving the hardest integration works is the cheapest insurance available on a mobile project.

Step five matters more than the rest combined. Framework comparison articles — including this one — generalise. Your specific hardest requirement, on your target devices, is the thing that will actually cause trouble, and it is testable in days.

What we usually recommend

For most business applications — internal tools, customer portals, booking and ordering apps, content and commerce apps — cross-platform is the right call, and which one follows from your existing team. For apps whose value is the hardware, we recommend native and explain why the abstraction would work against you.

Our mobile app development team builds in all three and will make the recommendation with the analysis shown rather than as an assertion. Where the app is a front end to systems that also need building, our software engineering team handles the backend alongside it.

Tell us what you are building and we will work through the decision with you.