Performance·September 2024·9 min read

The Impact of Progressive Web Apps (PWAs) on Mobile Web Experience

Progressive web apps still deliver real wins: offline caching, faster repeat loads, no app-store review. The "PWAs replace native apps" story from 2016-2019 didn't happen. Safari never shipped an install prompt, iOS installation stays a manual multi-tap flow, and Apple came within weeks of pulling home-screen web apps from the EU entirely in 2024.

What a PWA actually is

A progressive web app is a website that meets three technical bars: it's served over HTTPS, it registers a service worker, and it ships a web app manifest describing name, icons, and start URL (MDN — Service Worker API). Meet those bars and a browser can offer to install the site as a standalone app, cache it for offline use, and treat it more like software than a page.

That's the whole definition. There's no separate PWA runtime, no app-store binary, no bytecode. It's HTML, CSS, and JavaScript with two extra browser contracts layered on top.

PWA vs native app vs plain responsive site

Dimension	Plain responsive site	PWA	Native app
Distribution	URL, no install	URL, optional install	App store, mandatory install
Offline support	None	Yes, via service worker cache	Yes, native storage
Update path	Instant on next load	Instant, service worker fetches new assets in background	Store review + user update
Push notifications	No	Android: yes. iOS: only after home-screen install, iOS 16.4+	Yes
Install prompt	N/A	Android: automatic `beforeinstallprompt`. iOS: manual "Add to Home Screen" only	Store listing
Store review gate	None	None	Days to weeks per release

The install gap that never closed

Chrome fires the beforeinstallprompt event only after a user has interacted with the page at least once and spent roughly 30 seconds viewing it, on top of the HTTPS, manifest, and service-worker requirements (web.dev — What does it take to be installable?). That's a deliberate engagement gate, not a bug: Google doesn't want every site nagging a first-time visitor to install.

Safari has never implemented that event. On iOS, installing a PWA is still a manual flow: open the Share sheet, scroll to "Add to Home Screen," confirm. There is no programmatic prompt a site can trigger, and there's no signal a site can read to know whether the user has already installed it (MDN — Making PWAs installable).

Android's install prompt is an engagement-gated browser API. iOS's install path is a manual, undiscoverable menu item four taps deep in the Share sheet. Any PWA strategy that assumes parity between the two platforms is planning against a version of iOS that doesn't exist.

Discoverability is the part nobody budgets for

Even on Android, the engagement gate means a first-time visitor never sees an install option. They have to return, interact, and stick around 30 seconds before Chrome considers offering it. Most teams that assume "users will just install it" are quietly assuming a return-visit rate their analytics don't actually support.

On iOS, there's no browser-driven prompt at all, gated or otherwise. The only way a user finds the Share sheet's "Add to Home Screen" option is if a product team explicitly teaches them, usually with an in-page banner or tooltip built by hand. That banner is real engineering and design work, not something the platform gives you for free.

Push notifications inherit the same split

iOS push notifications for web apps require the app to already be installed to the home screen; there's no way to request permission from a browser tab first (WebKit blog — Web Push for Web Apps on iOS and iPadOS). That requirement shipped in iOS 16.4. Any re-engagement strategy built around push has to budget for the install step as a hard prerequisite on Apple platforms, not an optional nice-to-have.

The 2024 near-miss in the EU

In February 2024, Apple removed home-screen web apps entirely from iOS 17.4 betas for EU users, citing security and integration work the Digital Markets Act's browser-engine requirements would have forced (Apple Developer — Update on apps distributed in the European Union). After developer and regulator pushback, Apple reversed the decision before the final release and restored the existing WebKit-based implementation.

That's worth internalizing: PWA install support on Apple's platforms isn't a stable, permanent guarantee. It's a capability Apple has already threatened to remove once, for an entire regulatory region, on short notice.

Where PWAs still earn their keep

None of the above means PWAs are a dead pattern. It means the pitch has to be narrower than "app-like experience without the app store."

Offline-first caching is real and it works

A service worker sits between the page and the network as a programmable proxy, letting a site define exactly what happens on a request: serve from cache, hit the network, or race both (MDN — Service Worker API). For a content site or catalog browse experience, that means a shopper on a spotty subway connection still gets a usable page instead of a spinner.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      return cached || fetch(event.request).then((response) => {
        return caches.open('v1').then((cache) => {
          cache.put(event.request, response.clone());
          return response;
        });
      });
    })
  );
});

That's a cache-first strategy: try the cache, fall back to network, and backfill the cache for next time. It's a few lines of code and it's the mechanism behind every offline PWA claim you'll read.

Cache-first isn't the only strategy, and picking the wrong one shows

Cache-first is right for versioned static assets: a JS bundle with a content hash in its filename never changes once it's fetched. It's the wrong choice for anything that updates frequently, a product price or stock count, where serving a stale cached response silently is worse than a brief loading state.

A stale-while-revalidate pattern splits the difference: serve the cached response immediately for perceived speed, then fetch a fresh copy in the background and update the cache for the next request. That's the right default for content that changes but isn't safety-critical, like a blog post or a category listing page.

No store review means faster iteration

A PWA update ships the moment new assets deploy and the service worker's next fetch cycle picks them up. There's no multi-day review queue, no staged rollout percentage, no rejected build waiting on a fix for an unrelated guideline violation. For teams that ship weekly or more, that's a genuine operational advantage over native.

Served over HTTPS, no exceptions, including local dev via localhost.
Responds when offline, even if only with a fallback page, not a browser error screen.
Includes a web app manifest with name, a 192px and 512px icon, and a start_url.
Loads fast on first visit, since a slow first load undercuts the entire "instant repeat visit" pitch.

That checklist condenses Google's own PWA quality bar (web.dev — What makes a good Progressive Web App?). Every item is testable; none of them require guessing at browser internals.

The manifest can do more than most teams use

The web app manifest's shortcuts member lets an installed PWA expose key actions, like "New order" or "Track shipment", directly from a long-press on its icon, the same way a native app surfaces a quick-actions menu (MDN — Web app manifest, shortcuts). Combined with scope and display, this is where a PWA actually starts to feel like installed software rather than a bookmarked tab (MDN — Web application manifest).

Most teams ship the manifest's bare minimum, just enough to pass the installability check, and skip this layer entirely. That's a missed opportunity specifically on Android, where shortcuts are fully supported; it's a non-issue on iOS, where the manifest's app-like features are more limited regardless of how thoroughly you fill it out.

The metrics graveyard

Search "PWA case study" and the same three names surface every time: Pinterest, Twitter Lite, Starbucks, each with a specific percentage lift in engagement or conversion attached. None of those figures trace to a maintained, citable source today. The original blog posts have been taken down, redirected, or folded into unrelated marketing pages over the better part of a decade.

That doesn't make the underlying pattern false. Faster repeat loads and offline resilience plausibly help engagement. It means those specific numbers are folklore at this point, repeated in deck after deck without anyone re-verifying them, and they don't belong in a technical evaluation of whether PWA is right for your product.

If a PWA pitch leans on a decade-old percentage from a company that no longer publishes the source post, that's not evidence. Treat unsourced case-study stats as marketing folklore and evaluate the technology on its current, documented capabilities instead.

Deciding whether you need one

Scenario	PWA fit
Content or catalog site, mostly Android + desktop traffic	Strong. Install prompt works as designed, offline caching adds real value.
iOS-heavy consumer app needing push as a core retention lever	Weak. Install-then-push is a two-step funnel with real drop-off at step one.
Internal tool or admin dashboard, known device fleet	Strong. You control the browser, so the install-gap problem doesn't apply.
Product needing deep OS integration (camera, Bluetooth, background location)	Weak. Native APIs are still ahead of what the web platform exposes.

FAQ

Do PWAs still make sense in 2026?

Yes, for the specific job of a fast, cacheable, installable web experience, especially on Android and desktop Chrome. The mistake is expecting iOS parity with Android's install and push behavior.

Why doesn't Safari support the beforeinstallprompt event?

Apple has not implemented it. Installation on iOS stays a manual "Add to Home Screen" flow through the Share sheet, with no programmatic trigger a site can call (MDN — Making PWAs installable).

Can a PWA send push notifications on iPhone?

Only after the user has installed it to the home screen, and only on iOS 16.4 or later. There's no way to request push permission from an ordinary Safari tab (WebKit blog).

Is PWA support at risk of being removed by Apple again?

Apple already came close once, pulling home-screen web apps from EU iOS 17.4 betas over DMA compliance concerns before reversing course (Apple Developer). Treat platform support as a current fact, not a permanent guarantee.

What's the minimum a site needs to be installable?

HTTPS, a registered service worker, and a manifest with a name, 192px and 512px icons, and a start URL. Chrome adds an engagement gate on top: at least one interaction and around 30 seconds of viewing time (web.dev).

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.