Native, cross-platform, or both — how the decision is actually made

The question is usually asked as a budget question and answered as a preference, which is why it is so often answered wrongly. Cross-platform is not simply cheaper and native is not simply better. The honest framing is narrower: what must this app do that touches the operating system, and who is going to keep it alive for the next five years. Answer those two and the architecture is decided; the cost follows from it rather than the other way round.

What one codebase genuinely buys is not the build. It is everything after. A feature is specified once instead of twice, designed once, tested once and fixed once. Two OS releases a year are absorbed by one team rather than two. The saving on the first version is real but modest — perhaps a quarter — because product definition and interface design do not halve. The saving compounds afterwards, which is where most of an app's cost lives anyway.

Then the four categories that argue for native code, and they are specific rather than atmospheric. Sustained background work: continuous location, background audio, long-running Bluetooth. Deep platform surfaces: widgets, a watch app, CarPlay or Android Auto, App Clips, share extensions. Demanding graphics or camera work, where frame budgets and hardware pipelines matter. And third-party SDKs that ship native only — which in practice means banking, payment terminals, mobile device management, biometric vendors and a good deal of industrial hardware. If the brief contains two or more of these, treat cross-platform as the exception that must be argued for.

Enterprise briefs carry a fifth consideration that consumer ones do not. Managed distribution through an MDM, configuration pushed by policy, certificate pinning, device attestation, and single sign-on through an identity provider's own mobile SDK. Each of these is possible from a cross-platform codebase and each is documented primarily for native. The cost is not impossibility; it is that the well-trodden path is somewhere else, and a rare failure will be debugged at the bridge rather than in your own code.

Which leads to the answer most competent teams reach and few proposals state plainly: both. A React Native application, with native modules written in Swift and Kotlin exactly where the four categories demand it. The share of native code is usually small and is always known in advance, because it corresponds to a list of features that can be written down in the first week. This is not a compromise between two positions. It is the position.

The staffing argument then decides the remainder, and in this market it decides it firmly. Two native codebases require senior Swift and senior Kotlin engineers, continuously, for as long as the app exists. In Greece that team is expensive when it can be assembled at all, and the risk is not hiring — it is the departure three years in of the only person who understood the Android build. One TypeScript codebase can be maintained by the team that already maintains the web platform, sharing its types, its API and its conventions. For an organisation whose core business is not software, that is usually the decisive fact.

The decision is also reversible in one direction only, and it is worth knowing which. A cross-platform app can absorb native modules indefinitely, screen by screen, until in the extreme case it has been replaced from the inside. Two native codebases cannot converge; merging them is a rewrite. Starting cross-platform therefore keeps an option open, while starting native closes one — which matters when the roadmap at year three looks nothing like the roadmap that justified the original choice.

So the method, in order. Write out every feature. Mark the ones that touch the operating system rather than the network. If the marked list is short, build cross-platform and plan the native modules now rather than discovering them later. If it is long, or if a mandatory vendor SDK exists only as native, build native and stop looking for a saving that is not there. Then write the decision down with its reasons, because in two years someone will ask why, and the honest answer should not have to be reconstructed.