The claim in this title is the kind of line that shows up in agency pitch decks right before a quote for six figures of native development. It's worth taking apart rather than either accepting or dismissing outright, because the honest answer is conditional: a dedicated app earns its cost when a business's product depends on capabilities a browser genuinely can't offer, and it's an expensive distraction when it doesn't. The useful question isn't whether mobile matters — it obviously does — it's which specific capability a home-screen app buys you that a well-built mobile site doesn't, and whether your business actually uses it.
What a browser can and can't do
The gap between a mobile website and an installed app has narrowed a lot over the past several years, mostly because of what the web platform now calls a progressive web app (PWA): a site built with standard web technology that can be added to a home screen, run in its own window without browser chrome, work offline, and — on most platforms — send push notifications, all without going through an app store. On Android and desktop, that capability set is close to a native app's for a large share of business use cases.
iOS is the exception worth knowing about specifically. Apple added web push support for home-screen web apps starting in iOS and iPadOS 16.4, but with a real constraint: push only works once a user has explicitly added the site to their home screen first, not while they're simply browsing it in Safari — a limitation WebKit documents directly. That single detail changes the calculus for any business whose engagement strategy depends on push notifications reaching people who haven't already gone out of their way to install something.
Where the browser is genuinely the better call
Globally, mobile devices account for a clear majority of web traffic — StatCounter's platform market share data has shown mobile ahead of desktop for most of the past decade — and nearly all of that traffic arrives through a browser, not an app store search. That fact alone argues for a genuinely good mobile website before anything else: it's what shows up in search results, what a link in a text message opens, and what a first-time visitor encounters with zero install friction.
For most content sites, service businesses, marketing sites, and even a lot of eCommerce, that's the end of the story. A restaurant taking reservations, a local service business collecting leads, a publisher distributing articles — none of these depend on a capability the browser lacks, and all of them lose real traffic to the install step a native app requires. An app store listing is also its own SEO problem: it's discoverable inside an app store, not in general web search, which is a worse starting point for a business whose growth depends on people finding them who weren't already looking for them by name.
Where a dedicated app actually pays for itself
The capability gap that still matters comes down to a short list: reliable background push notifications on every platform including iOS Safari-browsed traffic, deep hardware access (NFC, Bluetooth peripherals, background location, biometric authentication tied into a secure enclave), consistently offline-first behavior across unreliable connectivity, and the habitual, repeated daily use that makes a home-screen icon worth the real estate it occupies.
As a hypothetical example — not a real client or case study — consider a business running a loyalty program tied to in-store purchases, using Bluetooth beacons to detect proximity and issuing time-sensitive push offers throughout the day. That combination of background hardware access and push reliability across all platforms is a legitimate case for native or cross-platform development, because a browser-based alternative would degrade meaningfully on at least one major OS. Compare that to a second hypothetical — a local bakery wanting an easier way for regulars to reorder — where a mobile-optimized ordering page with a home-screen PWA shortcut would likely deliver the same practical outcome for a fraction of the ongoing cost.
The pattern across both hypotheticals: the deciding factor isn't the size of the business or how mobile-first its customers are, it's whether the product depends on something a browser structurally can't do well.
The cost that doesn't show up in the pitch
What tends to get underweighted when a business decides to build an app is what happens after launch, not before it. A shipped app isn't a finished asset — it's an ongoing commitment tied to two operating systems that release new versions on their own schedule, each capable of deprecating an API, changing a permission model, or altering how background execution works in ways that require a code change on your side, not theirs. That's a maintenance cost with no natural end date, and it applies whether the app was built natively or with a cross-platform framework (a separate decision covered in more depth elsewhere).
There's also a distribution cost that's easy to underestimate: every update goes through a platform review process before reaching users, and every uninstall is invisible feedback a business doesn't get in the way it gets a bounce-rate number on a website. A mobile web presence can be updated the moment a fix is ready. An app update sits in a queue, however short, controlled by someone else's schedule.
A more honest version of the question
Instead of asking whether a business needs an app, the more useful exercise is asking what it would lose by not having one — specifically, concretely, in terms of a capability rather than a vibe. If the honest answer is "nothing we can't get from a fast, installable mobile site," that's a legitimate answer, not a lesser one. If the honest answer names a specific hardware dependency, an offline requirement that can't tolerate degradation, or a push-notification strategy that has to reach people who never deliberately installed anything, that's a real case for going native — and worth budgeting for the maintenance tail that comes with it, not just the build.
Further reading
