Do You Need an App, or a Good Mobile Website?

The question is almost never about features. Modern mobile websites do payments, cameras, maps, location and offline caching. The dividing line is whether you need a channel to the user — a way to reach them when they are not thinking about you — and on iPhone the web only gets that channel after a manual step almost no consumer knows exists.

Everything else in this decision follows from that one asymmetry, so start there rather than with a feature comparison.

The constraint that decides it

Apple's WebKit team documents Web Push on iOS for Home Screen web apps — a site with a manifest whose display is set to standalone or fullscreen — and states that a web app "can request permission to receive push notifications as long as that request is in response to direct user interaction."

Read the precondition carefully. The push capability belongs to the Home Screen web app, not to the site in a Safari tab. To get there, a visitor must open the Share sheet and choose Add to Home Screen — a flow Apple does not advertise, does not prompt for, and most people have never used deliberately.

So on iPhone, a website cannot notify someone who simply visited it. An app can, after one tap from a link and a permission dialog people recognise. If your business case depends on reaching users you do not currently have an email address for, that is the whole argument.

Android is not the same decision

Chrome documents the opposite behaviour. Its installability criteria say that a web app will "fire the beforeinstallprompt event and show the in-browser install promotion" once it is served over HTTPS, has a manifest with a name, 192px and 512px icons, a start_url and a display of fullscreen, standalone, minimal-ui or window-controls-overlay, and the visitor has engaged with the page — Chrome's heuristic is at least one tap and at least 30 seconds.

That is a real, browser-driven install path. Which means a progressive web app is a strong Android answer and a weak iOS one, and most businesses need both platforms. Planning a PWA as your whole mobile strategy works only if you have checked your own traffic split first.

What an app obliges you to

An app is not a one-off purchase; it is a subscription to two platforms' calendars.

The two SDK gates come from Apple's upcoming requirements and Google's target API policy, and they move every year. An app you stop maintaining does not simply age — Google's policy means apps targeting API level 34 or lower become unavailable on devices running newer Android versions.

Then there is the commission, if you sell anything digital.

Physical goods and services delivered outside the app are generally outside the commission, which is why plenty of retail brands lose nothing by staying on the web. A subscription or digital product is a different conversation, and it should happen before the build rather than after. We priced the rest of the ongoing obligation in our guide to what an app costs.

What a website gives you that an app cannot

The advantages run in the other direction and they are easy to undervalue because they are invisible when they work.

A page has a URL, so it can be linked, shared, indexed and advertised against a search. An app cannot be opened from a search result for a question it answers. A website ships a fix in the afternoon; an app ships it when review says so. A website has no minimum SDK, no annual target level, no store account, no rejection. And a visitor uses it without deciding to install anything, which is the single largest drop-off in the app funnel.

For a business whose customers interact a few times a year — a service company, most local businesses, most B2B — an icon on the home screen is not an asset. It is something to delete during the next storage cleanup. Our website development guide covers how we build for that case.

The honest middle

The sequence we recommend most often is not a compromise; it is a way to buy information before committing.

Build the mobile website first, properly — fast, indexable, doing the transaction end to end. Instrument it, and instrument it with the numbers that have consequences rather than the ones that fill a deck. If the pattern that emerges is weekly returning use by the same people, you have evidence for an app, and the app has a job to do on day one. If the pattern is a few visits a year, you have saved yourself two store accounts and an annual upgrade cycle, and you still have the customers.

Where a client already has both, the split we look for is which one the repeat customers use. That answer, from their own analytics, settles more arguments than any feature matrix.

Where we say no

We will not build an app whose entire justification is push notifications nobody has planned to write. A notification channel is an editorial commitment, not a technical feature; without someone owning what gets sent and why, it becomes the reason people uninstall.

We will not recommend a PWA as a complete mobile strategy to a business whose customers are mostly on iPhone, because the install step is real and most visitors will not take it. That is a limit on the technology, not a preference of ours.

And we will not quote an app when the honest answer is that the website needs rebuilding first. An app on top of a site that does not convert inherits the problem and adds a review queue to it.

Deciding in an afternoon

1. Do you need to reach people who are not currently on your site? If yes, on iPhone that means an app.
2. How often does a customer come back? Weekly supports an icon. Yearly does not.
3. What is your iOS-versus-Android split? A PWA answers Android well and iOS poorly.
4. Do you sell digital goods? Then the commission belongs in the model before you build.
5. Who owns the annual SDK upgrade? Both platforms have published dates, and they arrive whether or not anyone is budgeted for them.

If you want the two routes priced side by side against what your customers actually do, tell us what you are trying to reach them for — or start from the mobile app development page for how we scope the app side.