Native or cross platform: how we choose for mobile

Every mobile project starts with the same fork in the road. Do we build native, with separate codebases for iOS and Android, or do we go cross platform and share most of the code? People want a one word answer. The truth is that the right choice depends on your product, your team and your timeline, and we have shipped successful apps both ways.

What we try to avoid is choosing based on fashion. Cross platform tooling has matured enormously, but it is not free, and native is not automatically slow or expensive. Let us walk through how we actually decide.

The question behind the question

Before we talk technology, we ask what the app needs to do exceptionally well. An app is rarely just an app. It is a camera tool, or a maps tool, or a chat tool, or a checkout tool that happens to live on a phone.

If the heart of the product leans heavily on platform specific capability, like advanced camera control, Bluetooth devices, deep background processing, or tight integration with the operating system, native earns its keep. You get first access to new platform features, the best performance, and the fewest surprises when the operating system updates.

If the heart of the product is screens, forms, lists and standard interactions, which honestly describes most business apps, cross platform shines. You write once, you ship to both stores, and you keep one team instead of two.

What cross platform genuinely saves

The appeal is not a secret. One codebase means roughly one set of features to build, test and maintain rather than two. For a typical content and forms app, we see real savings in build time and, more importantly, in the months and years after launch.

Maintenance is where the saving compounds. Every bug fix and every new feature lands once. Two native codebases means doing much of that work twice, forever. For a small team, that ongoing cost is often the deciding factor.

• One team can own the whole app rather than splitting iOS and Android skills.
• Releases stay in step, so users on both platforms get features together.
• Shared business logic means fewer places for the two platforms to behave differently.

Where cross platform quietly costs you

We are not evangelists. Cross platform has real edges, and pretending otherwise leads to unhappy projects.

The most common issue is the last ten percent. The shared layer covers the bulk of the app cheaply, but the polish, the platform specific gestures, the truly native feel, often needs custom work that eats into the saving. Heavy animation and graphics intensive screens can also strain a cross platform layer in ways a native build would not.

There is also a dependency cost. You are tied to a framework and its community keeping pace with new operating system releases. Usually they do, quickly. Occasionally a major platform change arrives and you wait. Native teams never wait, because they sit on the platform directly.

Cross platform saves you the most when your app is mostly standard, and costs you the most when your app is mostly special.

How we actually make the call

In practice we score a project against a few questions and let the weight fall where it falls.

• How much of the app depends on deep platform features versus standard screens?
• What does the team look like, now and in two years? Can you sustain two native codebases?
• How important is pixel perfect platform feel to the brand and the users?
• How fast do you need to reach both stores at once?
• What is the realistic budget, including the years after launch, not just the build?

A logistics startup with a small team and a forms heavy app is a clear cross platform case. A health product built around real time sensor data and demanding background behaviour leans native. Many projects sit in between, and there we often go cross platform for the core and write small native modules for the few demanding parts. That hybrid is underrated and frequently the most sensible answer.

A note on the long game

Whatever you choose, the codebase you pick will be with you for years. We weight the long term cost heavily, because the build is a small slice of a product's life. An app that is cheap to build but painful to maintain is a bad deal dressed as a good one.

Our advice to founders is to be honest about what your app really is. If it is a beautifully standard business app, do not pay for two native codebases out of a vague sense that native is more serious. If your product lives or dies on platform specific capability, do not stretch a shared layer to do something it was never meant to. Match the tool to the job, and the cost and the quality both tend to take care of themselves.