Native or cross-platform: how to actually decide

Every mobile project starts with the same question, and it is usually answered by whoever has the strongest opinion rather than by anything about the product.

Native means separate applications for iOS and Android, each in its platform's own language. Cross-platform means one codebase producing both, using something like Flutter or React Native.

Both ship real products used by millions of people. Neither is the correct default. The decision comes down to four questions, and only the last one is technical.

1. How much of your product is unusual device work?

This is the deciding question and it is worth being honest about.

Most applications are, technically speaking, screens, forms, lists and network calls. Cross-platform handles all of that comfortably and has for years.

Where it gets harder is deep or unusual device integration: sustained background location, heavy real-time camera processing, Bluetooth peripherals, platform features that arrive in a new OS version, or anything where you need the newest API on release day. Cross-platform frameworks reach these through bridges, and bridges exist for what is common. The unusual thing is where you end up writing native code anyway, from inside a framework that makes it more awkward.

If your product is mostly ordinary interface over an API, this question does not push you toward native. If it is a fitness tracker, a hardware companion, or a camera product, it does.

2. How many people will maintain it, for how long?

Cross-platform's real advantage is not the initial build. It is every subsequent year.

One codebase means one bug fixed once, one feature built once, one test suite. With a small team that difference compounds — it is the difference between shipping to both platforms continuously and always having one platform lagging.

Native's advantage appears at scale, when you have separate iOS and Android teams who can work independently without coordinating on shared abstractions.

If the honest answer is "two developers, indefinitely", that is an argument for cross-platform, and a fairly strong one.

3. Do the two platforms need to feel different?

Some products should feel native to their platform — following each platform's own navigation patterns, gestures and conventions. Some should feel like themselves everywhere, with a strong brand identity that is identical on both.

Cross-platform is well suited to the second. It can do the first, but you spend the saved effort re-implementing platform conventions by hand, which erodes the reason you chose it.

This is a design and brand decision, and it is worth making deliberately rather than discovering it after the first build.

4. What can your team actually maintain?

The best technology choice your team cannot support is worse than the adequate one it can.

If you have Android engineers and no iOS engineers, that is a real input, not an inconvenience to be engineered around. If you will be hiring in a market where one skill set is far easier to find, that is a real input too. If you are outsourcing the build, ask specifically what happens at handover — a codebase your future team cannot maintain is a rebuild with extra steps.

The honest default

For most business applications — a marketplace, a booking product, an internal tool, an ordinary consumer app — cross-platform is the reasonable starting assumption, and the burden of proof sits with native.

Native earns its cost when the product is genuinely device-heavy, when platform-specific feel is part of the value, or when you have the team to support two codebases properly.

What should not decide it: what the loudest engineer prefers, what is currently fashionable, or which framework a proposal was written around before anyone asked what the product does.

Answer the four questions first. The technology falls out of the answers.