Your app is not your front door

Mobile website vs mobile app: which one should you build first?

The mobile website vs mobile app decision has a default answer for almost every business: the site comes first and the app comes second. The site is where strangers arrive, where search engines and AI answer engines can actually read you, and where a first purchase can happen with no install step in the way. The app is where people who have already chosen you come back. Building the app first means paying to run a channel before you have earned an audience to put in it.

One number drives most of the confusion. Apps take roughly 88 percent of the time people spend on the mobile internet, leaving about 12 percent for the mobile web, with the average user spending 3.6 hours a day inside apps.¹ Read fast, that looks like a verdict. Read properly, it describes where attention sits, not where customers are found.

The three things being compared

• Mobile website. A website that adapts its layout to phone and tablet screens, reached through a browser, with no download or installation.
• Native mobile app. Software built for one operating system, iOS or Android, installed from an app store, able to reach device hardware and work offline.
• Progressive web app (PWA). A website built with modern web technology so that it behaves like an app: installable to the home screen, usable offline, and on most platforms capable of push notifications, with no app store involved.

What do the app vs website statistics actually measure?

Time share and customer acquisition are different questions, and the headline figure answers only the first. The 88 percent counts minutes, and those minutes are extremely concentrated. Nearly half of all app time goes to a person’s single most-used app, and roughly nine in ten of those minutes go to their top five.⁷ Messaging, social and video own that distribution. A retailer’s app, a clinic’s app or a B2B product’s app is competing for what is left over.

The mobile web behaves in the opposite shape. It is shallow and wide: a very large number of short sessions spread across a very large number of sites, most of them opened by people who had not heard of the brand that morning. That is the profile of a first touch. Apps are deep and narrow, which is the profile of a habit. Neither shape is better. They do different jobs.

The real question is rarely app or site. It is which one is the front door, and which one is the room people come back to.

Mobile website vs mobile app: which one converts better?

On the raw numbers, the app. Mobile apps are reported to convert about 157 percent higher than mobile web pages on average, and within the same brand, app users are reported to convert 1.8 times better and to generate 1.5 times more revenue per session than mobile web users.¹ Those figures are real. They are also not a fair fight.

Everyone counted in the app funnel has already found the brand, decided to trust it, accepted the install, granted the permissions and kept the icon on the phone. That is a filtered population of loyal customers. The mobile web funnel contains everybody, including the person who landed from a search result three seconds ago and will never come back. Comparing those two conversion rates measures the selection at least as much as the interface. The honest version of the claim is narrower and more useful: for customers who already buy from you repeatedly, an app converts them better than a browser does.

So treat the widely circulated app vs website statistics as directional. Most of the strongest comparisons pass through aggregators rather than fresh primary research, and none of them are segmented by the variable that decides the answer, which is how often a given customer buys.

How fast does a mobile website have to be?

Fast enough that the browser is never the reason somebody leaves. This is where the mobile web loses winnable business, and it is an engineering problem rather than a structural disadvantage. Research by Google with SOASTA found the probability of a bounce rises 32 percent as mobile load time moves from one second to three, 90 percent from one second to five, and 123 percent from one second to ten.³ Separate Google consumer research put abandonment at 53 percent of mobile visits once a page passes three seconds.²

That work was published in 2017 and has been recirculated since without a fresh primary update, so treat the exact percentages as directional. The direction is not in doubt, and the gap has not closed. Mobile pages still load around 70.9 percent slower than desktop pages on average, and mobile carries a 56.8 percent average bounce rate against 50 percent on desktop and 51.6 percent on tablet.⁴

A slow mobile site does not only lose the sale in front of it. It also removes the visit that would have become an app download six months later.

Which one gets found: the app store or search?

Search engines and AI answer engines cannot crawl, index or cite anything locked inside a native app. Whatever share of attention apps hold, the mobile website is the only asset doing discovery work: ranking for the query, appearing inside a generated answer, being linked to by somebody else, being read by a person who has never heard of you. An app is a retention channel that arrives after discovery has already happened somewhere else.

There is a second-order effect worth naming, because it is newer than most comparisons account for. AI assistants increasingly answer the question a customer would once have typed into a search box, and they answer it from pages a crawler can reach. A company whose clearest explanation of its own product sits inside an app is absent from that layer, which means it is absent at the moment the buying question is actually asked. In that scenario the mobile site is not merely the cheaper channel. It is the only one taking part.

App stores also add an operating cost that build comparisons usually leave out. Every release passes a review queue. Platform policy changes land on somebody else’s schedule and can force rework at short notice. Ranking inside a store depends on install velocity and ratings, which are difficult to influence early. A mobile website ships an update the moment it is ready, with no gatekeeper standing between the change and the customer. That asymmetry belongs in the product development plan, not in a post-launch retrospective.

Is a progressive web app a real middle path?

Increasingly yes, with one platform caveat that decides a lot of cases. A progressive web app closes much of the capability gap: offline support, home screen installation, background sync and, on Android, push notifications, all from the codebase that already serves the mobile website, and all of it still crawlable. The market has moved accordingly, valued at roughly 3.5 to 5.2 billion dollars across 2024 and 2025 and growing at somewhere between 19 and 31 percent a year depending on the analyst.⁵ Around 60 percent of major digital brands now run PWAs to lift engagement, conversion and retention.⁶

The caveat is iOS. Apple still throttles web push and background capability on iPhone relative to Android, so a PWA that behaves like a native app on one platform behaves like a very good website on the other. If push re-engagement on iPhone is central to how the business makes money, a PWA is not a native replacement. If it is not, a PWA usually removes the reason to fund two native codebases at all. The mobile web vs native app comparison is therefore platform-specific, not universal, and anybody selling it as universal is selling something.

When does a business actually need a native app?

When the app has a job the browser cannot do. Three tests cover most cases. Does the product need device hardware or dependable offline use? Do customers interact several times a week rather than a few times a year? Is push re-engagement on iPhone a genuine part of the revenue model? Two yeses justify a native build. One yes usually points at a PWA. No yeses means the money belongs in the mobile site. Teams that run this through a structured design thinking process tend to find the real requirement is narrower than the original brief assumed.

A sequence that holds up

1. Fix the mobile site’s speed and checkout first. It is the cheapest conversion work available and it feeds every channel that comes after it.
2. Instrument repeat behaviour before scoping anything. Count how many customers come back within a month. If that number is small, an app has nobody to serve.
3. Ship a PWA ahead of a native build when the only missing pieces are offline use and a home screen icon.
4. Build native when a hardware or iPhone push requirement is doing real work, and scope it as a retention product for existing customers, not as an acquisition channel.

The order matters more than the choice. Where the answer is genuinely close, a short product development consulting review against your own repeat-purchase data will settle it faster than another round of internal debate. If you would rather test that against real numbers than opinions, get in touch.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.