We build mobile apps, and this article argues that you probably should not commission one. Both of those are true at the same time, because the apps worth building are a small subset of the apps that get commissioned.
The decision usually gets made backwards: someone decides an app is needed, then works out what it should do. Reversing that order resolves most cases in an afternoon.
The six reasons that hold up
If none of these applies to you, the honest recommendation is to put the budget into the web product instead.
- Offline, or genuinely unreliable connectivity. Field work, logistics, warehouses, remote sites. If the job happens where the signal does not, an app with local storage and a sync queue is not a preference, it is the requirement.
- Device capabilities the web cannot reach reliably on both platforms. This list shrinks every year, so check it against current support rather than against what was true when you last looked.
- Push notification as a core mechanism, not as a marketing preference. Web push is solid on Android and has been available on iOS since 2023, but with meaningful caveats around installation and reliability.
- Daily, habitual usage where a home-screen presence changes real behaviour. This is a genuine effect and it is also the reason most commissioned apps fail: it only applies if people would open the thing daily anyway.
- Store distribution as a commercial requirement. Sometimes a buyer, a partner or a procurement process simply requires it.
- Performance beyond what a mobile browser delivers for the specific interaction involved. Real, but far rarer than it is claimed.
The reasons that do not hold up
Four appear in almost every brief.
"Our competitors have one." Check whether their app has any reviews and when it was last updated. A large proportion of competitor apps are abandoned projects that nobody wants to admit to.
"It will improve engagement." An app cannot improve engagement with people who never install it, and the install step is the largest drop-off in the entire funnel. If the web experience is not already good enough to build a habit on, the app will not create one.
"It looks more professional." A slow, rarely-updated app looks considerably less professional than a fast website, and it is visible to everyone in the store listing.
"We want to be on the App Store." Being listed is not distribution. Store search sends almost no traffic to business apps that nobody is looking for by name.
What a progressive web app covers
Before commissioning native work, it is worth being precise about what the web already does, because the gap is narrower than most briefs assume.
- Installable to the home screen with its own icon and no browser chrome.
- Offline capability and background sync through a service worker.
- Push notification on Android, and on iOS when installed to the home screen.
- Camera, geolocation, files and payment request on both platforms.
- No store review, no store fees, no dual-platform release cycle, and updates that ship the moment you deploy them.
The remaining gaps are real: iOS push requires the user to install first, some device APIs are still native-only, and a store listing is a store listing. But for a customer portal, a booking tool or an internal system, a well-built PWA covers the requirement at a fraction of the cost.
The costs that are not in the quote
A build price is quoted once. An app is a recurring liability, and the recurring part is what surprises people.
- Annual OS releases on two platforms. Every year, something needs updating whether or not you changed anything.
- Store policy changes. Both stores periodically change requirements, and non-compliance means removal.
- Dependency and security updates, at a faster cadence than a website because the ecosystem moves faster.
- Device testing across a matrix that keeps growing.
- Developer account administration, certificates and provisioning, which fail at the worst possible moment.
Budget for this as an annual line, not a contingency. An app that is not maintained does not stay where it is; it stops working.
When the answer is yes
When one of the six reasons genuinely applies, build it properly: as a companion to the web platform, sharing the same APIs and the same design tokens, so features do not diverge and a fix does not have to be made twice.
Scope it to the two or three things that genuinely belong on a phone in that context, rather than porting the whole platform. A mobile app is not a smaller version of everything; it is the part of the job that happens away from a desk.
And decide the release lifecycle before the first line of code: store submission, review timelines, staged rollout, forced-upgrade paths and the OS versions you will support. Those constrain everything afterwards and are painful to change once you have users.