Few technical arguments burn as many hours as native versus cross-platform, and few are as decidable. The debate stays open because both camps argue from identity — “we’re a Swift shop”, “we’re a React team” — rather than from the application in front of them.
Here is the test we apply.
Ask how much of the product lives below the UI
Draw a line under the screens. Everything above it — lists, forms, navigation, a few animations — is commodity work that any of the modern toolkits handle well. Everything below it is where the platforms actually differ.
Below the line, the questions are:
- Does it need sustained background work? Location tracking, uploads that survive the app being backgrounded, scheduled sync.
- Does it need tight control of camera, audio or video? Manual exposure, low-latency audio, custom capture pipelines, on-device encoding.
- Does it need deep platform integration? Widgets, App Intents, Live Activities, share extensions, Wear/CarPlay, Bluetooth peripherals.
- Does it need on-device inference with real performance targets?
If two or more of those are core to the product rather than nice-to-have, go native. Every cross-platform framework can reach these through a bridge, and on a serious app you will spend more time maintaining bridges than you saved.
If none of them are, you are building screens over an API, and one codebase a small team can maintain beats two it cannot.
The costs each side hides
Native hides the second team. Two codebases is not 2× the work — it is closer to 1.6× — but it is 2× the release engineering, 2× the OS-upgrade tax every September, and a permanent coordination cost where a feature is “done” on one platform and not the other for three weeks. With four engineers that is manageable. With two, it is how you end up with an Android app that is quietly a version behind.
Cross-platform hides the escape hatch. The 90% you get for free is real. The remaining 10% costs disproportionately, and you cannot know in advance which 10% it will be. The mitigation is not to avoid cross-platform, it is to make sure someone on the team can write a native module — because sooner or later a SDK you need will only ship native bindings.
Where the current tools genuinely sit
Ignoring the marketing, in 2026:
- React Native with the new architecture is a reasonable default when the team already writes TypeScript. Sharing types — not components — with the web codebase is where the real leverage is.
- Flutter gives more consistent rendering and better tooling for animation-heavy interfaces, at the cost of a language most teams do not otherwise use. That cost is small if the mobile team is dedicated and large if you were hoping web engineers would help out.
- Native is not slow to write any more. SwiftUI and Compose closed most of the productivity gap that made cross-platform compelling a decade ago. The case for cross-platform today is codebase count, not development speed.
The decision nobody writes down
Whichever way it goes, write down why, with the date. Twelve months later somebody will propose switching, and the useful question will not be “which is better” but “which of the things we assumed has changed”. Without the note, you re-run the whole argument from identity again.
That note takes ten minutes. It is the highest-return document in a mobile project.