An honest decision framework for organisations being told they need to be in the app stores, from a company that builds mobile applications.
We build mobile applications. We also talk a reasonable number of organisations out of commissioning one, and the reasoning is consistent enough to be worth writing down.
The build is the smallest part. A mobile application commits you to an ongoing obligation that a website does not:
None of that is a reason not to build one. It is a reason to be sure, because these costs continue for as long as the app exists.
If your application is essentially forms, lists, dashboards and documents; if it is used at a desk or on a sofa; if usage is occasional rather than daily; if you need to ship fixes the same day — a responsive web application will serve you better and cost less to own.
Modern browsers handle installation to the home screen, offline caching and push notifications on both major platforms. The gap that existed a decade ago has narrowed considerably.
Four situations make it a straightforward yes:
Hardware access. Sustained camera use, Bluetooth peripherals, precise background location, NFC.
Real background execution. Work that must continue with the app closed — location tracking for a field workforce, large uploads that survive being backgrounded.
Offline as the normal condition. Not "occasionally has poor signal", but usually has none: warehouses, basements, vehicles, remote sites.
Daily habitual use. An app icon on a home screen is a genuine advantage for something opened every day. It is worth very little for something opened twice a year.
If none of those apply, the honest question is what the app gives you that a good mobile web experience does not.
Sometimes that is a real signal. Often it is evidence that someone sold them one.
The useful version of that question is: what do their users do in the app, how often, and is that a thing your users want to do? If the answer is that it is a wrapper around their website, you have learned something about their procurement process rather than about your users' needs.
If you are genuinely unsure, build the web application first and instrument it. Look at how many people add it to a home screen, how often they return, and where the experience is actually poor on a phone.
That gives you evidence rather than an assumption, and the web application remains useful either way. If the data says you need native, you will then be building it against a working product with real usage patterns instead of a specification.
The wrong version of this decision is expensive and hard to reverse. That is why it deserves more than a paragraph in a proposal.
A permanent link and an email link, rather than a row of share buttons. A share widget would mean loading somebody else’s script — and their tracking — on every article you read here.