Native, Cross-Platform or PWA: How to Choose for a Mobile App

Three ways to put an application on a phone, with genuinely different economics. The choice is decided by four questions, and none of them is which technology is best.

The mobile decision is usually presented as a technology comparison, which is why it takes so long to resolve — technology comparisons have no natural end. It resolves quickly when treated as four questions about the product.

First, the three options in one line each. A native app is built with each platform's own tools, once for iOS and once for Android. Cross-platform development builds one codebase that produces both apps, rendering real native components. A progressive web app is a website built to be installable and to work offline, with no app store involved.

Question one: does it need to be in the app store?

Not technically — commercially. For a consumer product, store presence is discovery and credibility; people look for apps where apps live, and an installable website does not appear there.

For an internal tool, a field application or a product used by a known set of business customers, the store is often pure overhead: review delays, two submission processes, and a barrier between you and shipping a fix. A progressive web app removes all of it, and updates reach users the moment you deploy.

If the store is not needed, this question alone can save the majority of the budget.

Question two: what does it need from the device?

Ordinary things — camera, location, notifications, offline storage, biometric unlock — are available to cross-platform frameworks and, with more variation between platforms, to progressive web apps.

Some things are not. Sustained background processing, deep integration with platform features, high-performance graphics, specialised Bluetooth or sensor work, or anything requiring the newest platform capability the week it ships — these push towards native.

Be specific here rather than aspirational. "We might want augmented reality later" is not a requirement; it is a reason to over-build now for a feature that may never be prioritised.

Question three: how much does the feel matter?

For most business applications, cross-platform output is indistinguishable from native to the people using it. It renders the same components and follows the same conventions.

For a consumer product whose competition is polished and whose users have alternatives one tap away, the last increment of smoothness is part of the offer. That is a genuine argument for native, and it is a much narrower set of products than the number that invoke it.

Question four: who will maintain it, and with what budget?

Native means two codebases, which in practice means two skill sets and every feature built twice. That is a permanent multiplier on the cost of change, not a one-off cost at the start.

It also affects consistency. Two codebases drift: a feature ships on Android in March and on iOS in May, and the two behave subtly differently. Cross-platform keeps them in step by construction, which for a small team is often worth more than any performance difference.

Progressive web app for internal tools, field applications, and anything where the audience is known and would not otherwise install software. Cheapest to build, cheapest to change, no store to manage.
Cross-platform for the large middle: a consumer or business app that needs store presence and ordinary device features. One codebase, both platforms, feel that is good enough for nearly everything.
Native when performance or device access is the product, when a platform-specific experience is a competitive requirement, or when you already have strong native capability in-house.

Two things that cost more than the choice itself

Whatever you pick, the backend is the same work. A mobile app is usually a client for an API, and that API — its design, its authentication, its handling of poor connectivity — is frequently the larger half of the project. Teams comparing mobile technologies for weeks often have not started this conversation.

And releasing is not the end of the platform cost. Both stores require periodic updates for new operating system versions, and an app left alone for two years may simply stop being accepted. Budget for maintenance from the start, or plan to rebuild sooner than you expect.