Native App, Web App, or Neither?

Somebody says "we need an app" and the room agrees, because nobody wants to be the person arguing against a phone. A budget appears. Six months later there is a store listing with a few hundred installs, most of them from the team and their families, and a support queue asking why the thing that used to work in a browser now requires a download.

The native vs web app decision has four dimensions that actually matter: what the device will let the software do, how it reaches people, what an update costs, and whether a stranger can find it at all. Feature lists are noise. Those four questions decide the outcome, and they usually decide it against native for the kind of business that asks the question in the first place.

That is a position, so here is the defence, along with the cases where we would build native without hesitating. There are real ones. The point is not that apps are bad. The point is that "app" is an answer, and most teams arrive holding it before anyone has written down the question, which is what a technical discovery should produce before a single line of the work is estimated.

What "we need an app" usually means

Listen to how the request gets justified and you can usually hear the real problem underneath it. Four versions come up again and again, and only one of them is genuinely about a phone.

"Our site is slow and awkward on mobile" is a website problem wearing a costume. "We want to send push notifications" is a retention problem, and notifications are one mechanism among several. "Our competitors have one" is positioning anxiety, and the useful response is to ask what their app does that their site cannot. "We want to be on customers’ home screens" is at least about the device, though it is worth knowing that an icon somebody stops tapping is a worse outcome than no icon at all.

Underneath all four sits a question about what the business is actually selling and to whom, which our parent company set out in what a company actually sells. If the answer is a service people buy once or twice a year, a home-screen icon is a monument rather than a channel. If the answer is something people touch daily, the calculation changes completely, and it changes for reasons of frequency rather than reasons of technology.

Capability: what the device will actually let each one do

This is where the argument used to end and no longer does. The capability gap is real but narrower than most briefs assume, and it is narrow in a lopsided way: the browser has caught up on almost everything that happens while the user is looking at the screen, and remains far behind on everything that happens when they are not.

The gap that is still real

Background execution is the big one. Software that must run when the app is closed, sync while the phone sits in a pocket, or respond to a location change hours after the user last opened it, needs to be native. Continuous sensor access falls into the same category, as does deep integration with the operating system: contributing to the share sheet, registering as a handler for a file type, running a home-screen widget, or talking to specific hardware over Bluetooth with any reliability. Sustained, frame-critical graphics work belongs here too.

The gap that closed while nobody was watching

Camera and microphone access, geolocation, offline storage, installation to the home screen, and notifications on most platforms are all available to a web application now, with caveats that vary by operating system and browser. Offline is the one needing real design work rather than a switch: deciding what is cached, what happens to a change made with no signal, and how conflicts resolve when the connection returns. That is a data-modelling problem more than a platform one, and it lands in the same territory as choosing a database you will not regret, because the sync rules are the hard part in both cases.

The other thing that closed is the perception gap. A web application that responds to input within a few dozen milliseconds and does not shift its layout under the user’s thumb reads as an app to almost everybody, whatever it was built with. Most complaints that a web experience "feels like a website" are complaints about responsiveness and layout stability, both of which are measurable and both of which are fixable without changing platform.

Distribution and discovery: the two costs nobody prices

This is the dimension that ends most app projects quietly, about a year after launch, without anyone naming it as the cause.

Every install is a negotiation

A link opens. An app has to be searched for, chosen, downloaded, waited for, opened, and usually signed into before it does anything at all. Each of those is a step where people leave, and the drop is steepest for exactly the audience an app is normally pitched at: people who have not bought anything yet. Installs are also a famously misleading number to celebrate, which is the argument in activation beats acquisition. An install is not a user. It is a person who has agreed to think about it later, and later frequently means never.

Strangers find web pages; they rarely find apps

A page can be indexed, linked, quoted, shared into a group chat and opened by someone who has never heard of you. An app store listing is discoverable by store search, and that is close to the whole of it. If your growth depends on being found by people describing their problem rather than typing your name, native distribution removes your main channel and replaces it with a marketplace you do not control. This is why an app almost never substitutes for a website that can be found and read; at best it sits behind one, serving people who already decided.

The update cost that arrives in year two

Shipping a fix to a web application is a deploy. Everybody has it on their next page load, and there is exactly one version of your software in the world. Shipping a fix to a native app means building, submitting, waiting for review, then waiting again for people to update, which some of them will not do for months. You will support several versions of your own product at once, and the oldest of them will generate most of the support tickets.

There is also a floor cost that exists whether or not you touch the product. Operating systems release annually, deprecate APIs, change permission models and eventually stop accepting builds made with old toolchains. A native app nobody changes still needs work every year simply to remain installable. That is a standing obligation, and it belongs in the category of debt you decide about deliberately rather than something you discover when the store sends a deprecation notice with a deadline attached.

Two platforms doubles the surface, and cross-platform frameworks reduce that without removing it. You still hit platform-specific behaviour at the edges, still maintain two store listings, still handle two review processes, and still need someone who can read a native crash log at two in the morning. Frameworks are a good answer to the cost of writing the code twice. They are a weaker answer to the cost of operating it twice.

Native vs web app, on the dimensions that decide it

Set against each other, with the question that usually settles each row in the last column.

Most of these requests are answered by a better website

Take the four justifications from earlier and follow each to its actual fix. Slow and awkward on mobile is a performance and interface problem: cheaper than a build, faster to ship, and it improves the experience for the people already arriving rather than only for the fraction who would have installed something. Notifications have web and email equivalents that reach more of your audience than an app will. Competitive anxiety is settled by looking at what the competitor’s app does, which is frequently a wrapper around the same pages.

There is a genuine third option in that list, and it deserves its own name. Sometimes the answer is neither: no app, and no website rebuild either. What the business needs is a web application behind a login, which is a different object from a marketing site and gets confused with one constantly. The dividing line we use is simple: on a website the visitor is reading, and in an application the visitor is doing work that produces something which persists.

Software of that shape is the clearest case for the web rather than a phone. Prooflin is an example of the type: findings, severities, priorities and recommendations resolved into professional reports somebody reviews. That work happens at a desk, the output is shared as a link, and nothing about it improves by being downloaded from a store. Ask where the work physically happens before arguing about platform, because the answer is often already decisive.

An app is not a channel. It is a place you send people who already arrived somewhere else, and it fails quietly when nobody has done the arriving.

When native is clearly the right answer

The concession, and it is not a grudging one. There are cases where recommending a web application would be wrong, and each of them is recognisable before a single estimate is written.

• The software must run while closed. Background sync, continuous tracking, geofenced triggers, delivery and logistics tooling. If it only works when someone is looking at it, it does not work.
• It is used many times a day by the same people. High frequency justifies install friction, because the cost is paid once and the convenience is collected daily.
• It talks to hardware. Bluetooth peripherals, card readers, wearables, industrial equipment, anything needing a reliable persistent connection to a physical device.
• It is field software for a known workforce. Distribution is not a problem when you can require the install, and discovery is irrelevant when the audience is on your payroll.
• The interaction is the product. Games, camera-first tools, sustained real-time graphics, and anything where a dropped frame is a defect rather than a nuisance.

If your case is on that list, build the app and build it properly. Mobile app development done well is not a scaled-up website project, and treating it as one is how teams end up with a native shell wrapped around web pages, carrying the costs of both models and the advantages of neither.

How we would decide, in an hour

You do not need a discovery phase to get most of the way here. Answer these in order and stop at the first one that gives you a clear result.

1. Does it need to run when nobody is looking? If yes, native, and the rest of the questions are academic. If no, keep going.
2. How often will one person use it? Daily earns an install. Monthly does not, and quarterly certainly does not, whatever the internal enthusiasm.
3. Who are the first hundred users, by name or by role? If you cannot list them, you have an acquisition problem, and an app makes that harder rather than easier.
4. Can you require the install? Employees, contracted partners and enrolled members can be required. The public cannot, and asking is a cost you pay on every single person.
5. Who maintains it in two years? Name the person or the budget line. A native app without an owner becomes uninstallable on its own schedule, not yours.
6. What breaks if you ship the web version first? If the honest answer is nothing much, ship that, watch what people do with it, and let demand for an app come from usage rather than from a meeting.

The condition that reverses all of this is worth stating clearly. If you already have an engaged audience opening your product several times a week, and their main complaint is friction rather than absence, then native stops being a growth bet. It becomes a retention improvement for people who have already told you they want it, and the case for building it is much stronger than anything else in this piece suggests.

Everyone else should write down the sentence beginning "we need an app because", read it back, and check whether the word after "because" is about the device at all. It usually is not. If you want a second read on where yours lands, send us the sentence and we will say which of the three answers we would argue for.