Native or Cross-Platform: Deciding Like an Engineer

Every team building a mobile product faces the same early decision: one shared codebase, or one per platform. It is usually argued with slogans — "native is faster", "cross-platform is cheaper" — and both slogans are true just often enough to be dangerous. The honest answer is that this is an engineering trade-off, and like most engineering trade-offs it depends on what your product actually is.

We are a native studio, so you know our bias up front. But we arrived at that focus by making this decision many times, not by ideology — and there are products we would steer toward cross-platform tools. What follows is the framework we use.

Start with the ceiling, not the starting cost

Cross-platform frameworks optimise the first six months: one team, one codebase, features landing on both platforms at once. That is a real advantage and it is why they are popular. Native optimises everything after that: the ceiling of what the app can feel like, how directly it can use the platform, and how predictably it ages as iOS and Android evolve underneath it.

So the first question is not "what is cheapest to build" but "where does this product need its ceiling to be". A tool used weekly by a captive audience has different requirements from a consumer product competing for a place on the home screen against apps built by teams who sweat every frame.

Where native genuinely earns its cost

• Platform feel. Navigation transitions, scroll physics, context menus, haptics — users calibrate against the other apps on their phone, and the calibration is unforgiving. Matching it through an abstraction layer is possible but it is permanent, skilled effort; with native it is the default.
• Deep device integration. Camera pipelines, Bluetooth, NFC, precise location, background processing, widgets, watch and TV companions. Every layer between your code and the OS adds latency to adopting new platform capabilities — native teams ship them the year they launch.
• Performance under stress. Long lists of media, real-time rendering, large offline datasets, older devices. Cross-platform performance is good until it is not, and when it is not, the debugging happens through two runtimes instead of one.
• Longevity. A ten-year product will ride through many OS releases and framework fashion cycles. Swift and Kotlin are the platforms' own languages; their deprecation risk is as low as mobile risk gets.

Where cross-platform is the right call

Honesty cuts both ways. A shared codebase is a sensible choice when the interface is predominantly forms, lists, and content; when the team is small and the budget genuinely cannot support platform depth; when the app is an internal tool where platform feel matters less than delivery speed; or when validation speed on both platforms at once is the whole point and a later rebuild is an acceptable, priced-in outcome.

The questions we actually ask

1. 01Will users compare this app to the best consumer apps on their phone, or to a spreadsheet it replaces?
2. 02Does the roadmap touch camera, sensors, offline sync, maps, payments, or background work beyond the basics?
3. 03Is this a product you expect to run and evolve for five-plus years?
4. 04Could you fund two platform engineers, or one team that owns both native codebases?
5. 05If the answer to the first three is yes, what would re-platforming later actually cost — in money, and in the market window?

Three or more "yes" answers and native is usually the cheaper decision measured over the life of the product, even though it is rarely the cheaper decision measured at the first invoice. The gap between those two measurements is where most mobile regret lives.

A note on "native later"

Teams sometimes plan to validate cross-platform and rewrite native "once we have traction". It can work, but plan it like the migration it is: the rewrite competes with the roadmap at exactly the moment traction makes the roadmap urgent. If you take this path, keep the domain logic portable, keep the design system platform-aware from the start, and write the rewrite trigger down — a metric, not a mood — so the decision gets made on evidence.