Native vs Cross-Platform: How to Actually Decide

The performance argument that most of these comparisons are built on stopped deciding anything years ago, and the thing that still does is rarely mentioned: your app has dated, published obligations to Apple and Google, and your framework choice decides whether you meet them directly or through someone else. Both major cross-platform frameworks are currently meeting them. That is a fact about today, and it is the thing you are actually buying.

This guide is about how to weigh that, and about the part of "one codebase" that is never one codebase.

The deadlines are real and they are dated

Start here, because it is the part clients are never shown. Both platforms publish hard gates, and they move every year.

Apple's upcoming requirements page sets the first. Google's target API level policy sets the second, and adds a consequence most people miss: existing apps that target API level 34 or lower are only available on devices running an Android version at or below the app's target level. An app you stop updating does not merely stagnate — it quietly disappears from newer phones.

That cadence is the real recurring cost of owning an app, and it applies whichever way you build. We put numbers around the rest of that in our guide to what an app costs.

What the frameworks actually do with those deadlines

Now the useful question: does a framework put you ahead of those dates or behind them? The record is checkable, and in 2026 it is good.

React Native's release notes for 0.81, published 12 August 2025, state that "Android apps built with React Native 0.81 will now default to targeting Android 16 (API level 36)." Google's deadline for that target was 31 August 2026. The framework arrived roughly a year early, and React Native has shipped a release every two months since.

Flutter's supported platforms page for 3.47 lists Android API 24 to 37 as supported and iOS 15 to 26, with continuous-integration testing on API 24 to 36 and on iOS 18 and 26. Both current platform versions are covered.

So the honest position is not that cross-platform frameworks lag. It is that they currently lead, and you are buying a dependency on that continuing. The same React Native release shows the other edge of it: 0.81 raised its own floor to Xcode 16.1, and noted that prebuilds were not supported under the Xcode 26 beta because the IDE had made Swift explicit modules the default. Small frictions like that are the texture of the dependency, and they land on your team's calendar, not the framework's.

The part that is never one codebase

The phrase "one codebase" survives because it is true about the half of the app people look at. Screens, navigation, state, forms, business logic — genuinely shared.

What is not shared is everything that touches the operating system. Push notification behaviour, background execution rules, widgets, Live Activities, watch apps, health and payment frameworks, file providers, share sheets, deep links registered with the OS. Each of those needs platform-specific work on both sides, done by someone who understands that platform, whichever framework wraps it.

The practical consequence is an estimating one. Budget a cross-platform app as one shared codebase plus two thin native layers, sized by how much of your product lives in that second category. A booking app with a login and a list is almost all shared. An app whose value is a home-screen widget, a background sync and an Apple Watch companion is not, and the cross-platform saving on it is much smaller than the brochure suggests. Our mobile app development guide covers how we scope that split before quoting.

The minimum-version question, which is not symmetric

Teams spend real time debating which OS versions to support, and on iOS the debate is nearly empty.

Apple measured on 7 June 2026 that 79% of all devices, and 86% of devices introduced in the last four years, run iOS 26. Supporting iOS 15 rather than iOS 18 buys you a slice of a slice — and costs you every API added since, plus the testing matrix to prove it still works.

Android is a different decision, because its version distribution is genuinely spread out. There the floor is a commercial choice about which devices and which markets you are willing to lose, and it deserves an actual answer rather than a default. Flutter's floor is API 24, so below that no framework question arises: you are writing native or you are not shipping.

Note the caveat attached to Apple's figure, because it changes how much weight it carries. Apple measures "devices that transacted on the App Store" — an active-buyer population, not an install base. For deciding what a paying customer runs, that is arguably the right denominator. For estimating reach into a price-sensitive market, it flatters the newest version.

When we recommend native

We are not neutral here, and we would rather say where than imply we have no view.

We recommend native when the product is the platform integration. Sustained camera or sensor processing, background work that has to survive aggressive OS power management, deep widget and watch experiences, anything where a new OS capability is the roadmap rather than a nice-to-have. In those apps the framework spends its time getting out of the way, and you pay for a layer you are constantly working around.

We also recommend native when you are shipping to one platform. A cross-platform framework used for a single target is a dependency with no upside — you took on the maintenance and declined the benefit.

And we recommend cross-platform, without hedging, for the large middle: apps that are screens over an API, launched on both platforms, by a team that will not staff two native practices. That is most business apps, and pretending otherwise to sell a bigger build would be dishonest.

Where we say no

We will not quote a cross-platform build as "one app" when the specification is full of platform-specific behaviour. The number would be wrong and both sides would find out in month two.

We will not recommend native to a client who needs both platforms, has one budget, and has no plan to hire. Two native codebases maintained by nobody is worse than one cross-platform codebase maintained by someone.

Deciding in an afternoon

1. How much of your product touches the OS? Screens over an API point to cross-platform. Widgets, background work and sensors point to native.
2. Are you shipping to both platforms, honestly? If one is theoretical, build for the real one natively.
3. Who meets next year's SDK deadline? Both dates are published. Make sure someone owns them in writing.
4. What is your Android floor? On iOS this is nearly decided for you. On Android it is a market decision with revenue attached.
5. Would you rewrite rather than migrate? If switching later is unacceptable, weigh the choice as a multi-year commitment, because that is what it is.

If you would rather have the split priced than argued, tell us what the app has to do and we will say which parts are genuinely shared, which are not, and what each route costs to keep alive — or start from the mobile app development service page for how we scope it.