Does your business need an app, or is a mobile website enough?

"We need an app" is often the first sentence rather than the conclusion. But an app is not a format, it is a commitment: two platforms, store rules, signing keys, and updates you have to ship even when you changed nothing yourself. So the useful starting question is not "native or cross-platform" but whether the solution needs phone capabilities at all. If it does not, a mobile website does the same job sooner and costs less to keep running.

In short

• An app is justified when the solution needs phone capabilities, or has to work without a reliable connection. Otherwise a mobile website is usually enough.
• Notifications are no longer an argument on their own: since iOS 16.4 web push works, but only once the user adds the site to their home screen.
• Background work - syncing while the app is closed - still sits on the native side. That, rather than notifications, is usually the real boundary.
• App stores change your release rhythm rather than your build: every update goes through review, so fixing a mistake is no longer instant.
• Before choosing a platform, agree who owns the App Store and Google Play accounts and the signing keys. That matters more than the name of the technology.

When phone capabilities are genuinely required

It helps to separate what is wanted from what the solution cannot work without. Photographing a document works in a browser. Location while the user is looking at the screen works in a browser too. The boundary starts where something must happen with no app open, or where you need deeper access to the device.

• Location tracking or data syncing in the background, while the app is closed.
• Bluetooth connections to equipment - scales, printers, sensors.
• Dependable offline work over longer periods, where data is stored locally and reconciled later without duplicates.
• Distribution through the stores, or internal distribution to staff with managed versions.
• NFC, deep integration with phone features, or working with the device file system.

One need, four platform routes

Illustrative scenario, not a description of a client project. Imagine a service company whose technicians work at customer sites: they need to mark work as done, photograph the result and receive the next job. Connectivity at those sites is poor. The same need is now assessed across four routes on the same four axes: phone capabilities, offline behaviour, releasing, and the scope of ongoing support.

Route one: a mobile website

• Phone capabilities: camera and location work while the user is in the app. In the background, they do not.
• Offline: short drops are survivable, long stretches without a connection are not dependable.
• Releasing: a fix reaches everyone at once, with no review and no action from the user.
• Support: one codebase and one release path. The smallest scope of the four.

Route two: an installable web app on the home screen

• Phone capabilities: as on the website, plus notifications - but only after the user adds it to their home screen.
• Offline: better than a plain website, because data can be held locally, though storage and background capability remain limited on iOS.
• Releasing: as on the website, with no store review.
• Support: one codebase, but the install flow and offline behaviour need testing in their own right.

Route three: one cross-platform codebase

• Phone capabilities: available, including background work and Bluetooth.
• Offline: solvable in the normal way, with data stored on the device and synced later.
• Releasing: through both stores, with every update going through review.
• Support: one codebase, but testing happens on both platforms and some features are still written separately.

Route four: separate native apps

• Phone capabilities: complete, and the newest ones arrive here first.
• Offline: full control.
• Releasing: through both stores, as with the cross-platform route.
• Support: two codebases, two test cycles and two release paths - the largest ongoing scope.

In this scenario the third route looks justified: background and offline work are needed, but nothing demands two separate applications. The first route would be too fragile given the connectivity, and the fourth would be an unnecessarily large support commitment. That will not always be the answer: change one condition and the conclusion changes with it.

What this comparison does not tell you

The comparison shows what changes when you pick a route, not what it costs. Cost follows the scope of the features, the integrations and the state of your existing systems, so no general figure can be given without a specific need - any number here would be an assumption rather than an estimate. It also says nothing about marketing: an icon on the home screen does not bring users by itself.

• If not a single feature needs phone capabilities, the app can be postponed with no harm to the product.
• If all you need is notifications, first check whether your users would realistically add the site to their home screen.
• If you already have a working website, it is often more rational to fix its mobile use first and only then consider an app.

How to decide in one conversation

• List the features and mark each one for whether it requires phone capabilities. If none do, you already have your answer.
• Describe what must happen with no connection, and what happens when it comes back. This answer usually decides the platform.
• Agree who owns the store accounts and the signing keys, and write it down before work starts.
• Decide how often you want to ship updates, knowing each one goes through review.
• Choose a first usable version: one workflow end to end, rather than a list of every feature.

Common questions

• Can we start with a website and move to an app later? Yes, and it is often sensible: the shared part - the data and the logic - stays, and the app is added once there is a real need for background work.
• Who should own the App Store and Google Play accounts? The business. The accounts and signing keys should be in your name, so that shipping an update never depends on one contractor.
• Is an app more visible in search? No. App content is not the same thing as website content for search engines - if visibility matters, the website is what addresses it.

If you want to make this decision against a concrete need, the useful starting point is a feature list with one question against each: would it work without phone capabilities. With that list in hand the platform conversation is short and ends in a specific choice.