Why Add a PWA to Your Site: The Honest Value Case for a...

Somewhere in the last few years, a lot of small businesses got quoted tens of thousands of dollars to build a mobile app, told they needed to be "in the App Store" to be taken seriously. Most of them did not need a native app. They needed the three or four things a native app does that a website historically could not: install to the home screen, work when the network drops, send a push notification, and feel like a real app instead of a tab. A progressive web app, or PWA, is the web platform's answer to exactly those three or four things. It is not a rewrite. It is your existing site, enhanced, so it can do the app-like parts without the app-store toll or a second codebase.

This post is the honest version of the pitch. What a PWA actually is, where the value is real and cited, the famous case-study numbers with their real dates attached, and the caveats, especially on iPhone, that the breathless blog posts leave out.

What a PWA actually is

Strip away the marketing and a PWA is a website that meets a short technical checklist. Mozilla's definition is that it is "an app built with web-platform technologies" that "can run on multiple platforms and devices from a single codebase." Google's web.dev frames it around three pillars: a PWA should be Capable (able to use modern browser APIs like push and offline storage), Reliable (fast, and usable on a flaky network or none at all), and Installable (it launches from the home screen in its own window, not a browser tab).

Concretely, you turn a normal website into an installable PWA by adding two files and serving them over HTTPS:

A Web App Manifest, a small JSON file that gives the app a name, icons, and a display mode like standalone so it opens without browser chrome.
A Service Worker, a script the browser runs in the background that can cache your site for offline use, speed up repeat visits, and receive push messages.

That is the whole foundation. Add those to a site you already have, and a supporting browser will offer to install it, run it offline, and let it receive notifications. You can check whether your own manifest is complete with the free Web App Manifest audit tool on this site. The point worth holding onto is that a PWA is not a category of app you go build from scratch. It is a set of enhancements you add to the site you already run.

The value, part one: no app-store tax, one codebase

The first argument is financial, and it is the one a small-business owner feels immediately.

Native apps are taxed. Apple's App Store takes a standard commission of 30 percent on digital goods and services, reduced to 15 percent for developers earning up to $1 million a year under its Small Business Program, which began January 1, 2021. Google Play charges 15 percent on a developer's first $1 million of revenue each year and 30 percent above that. A PWA is distributed from your own URL, so there is no platform commission on what you sell through it and no app-review gatekeeper deciding whether your update ships. You still pay ordinary web payment-processing fees if you take money, on the order of 3 percent through a processor like Stripe, but that is a different universe from a 30 percent platform cut.

The second argument is that a PWA is one codebase. A native strategy usually means building and maintaining a separate iOS app and a separate Android app, on top of the website you already have. A PWA, in Mozilla's words, "can run on multiple platforms and devices from a single codebase," because it is the website. You maintain one thing. For a business that was quoted for a website plus two native apps, that is not a small saving. It is most of the budget.

The size difference is not subtle either. When Starbucks built its ordering experience as a PWA, the firm that built it reported the result was 233 kilobytes, "99.84% smaller than the 148MB size of the original iOS mobile app" (that was around 2017). Twitter's PWA, Twitter Lite, loaded its core in about 600 kilobytes "over the wire vs. 23.5MB of downloaded data needed to install the native Android app" (2017). A PWA installs in the time it takes a native app to show its splash screen.

The value, part two: speed, offline, and getting people back

The second cluster of value is about behavior. Faster sites convert better, offline resilience keeps people from bouncing, and an installed icon plus push gives you a way to bring them back.

Speed is the best-documented link to money on the web. Deloitte's 2020 "Milliseconds Make Millions" study found that improving mobile load time by just one tenth of a second lifted retail conversions by 8.4 percent and average order value by 9.2 percent. The BBC, cited by Google, "found they lost an additional 10% of users for every additional second their site took to load." A service worker's caching is a direct lever on that number: the second visit to a PWA can come largely from the local cache instead of the network, so repeat visits are fast in a way a plain site is not.

Offline resilience is the part that plays in the real world of subways, elevators, and rural signal. Trivago reported that after launching its PWA, 67 percent of users who went offline and came back continued browsing (2017). That is retention the old mobile web simply lost when the connection dropped.

And the installed icon changes the relationship. An installed PWA sits on the home screen like any app, launches in its own window, and, where supported, can send push notifications to pull a customer back. That re-engagement is where the app-like case studies cluster, and it is genuinely the thing a bookmark cannot do.

The famous numbers, with their real dates attached

You have probably seen the PWA case-study stats. They are real, they come from the companies themselves, and almost all of them are from the 2016 to 2021 window when the platform was new and every early adopter published a triumphant blog post. Treat them as directional evidence that the pattern works, not as a promise of what your site will do in 2026.

AliExpress (2016): a 104 percent increase in conversion rate for new users across all browsers, and an 82 percent increase in conversion on iOS, with twice as many pages visited per session (from Google's web.dev case study).
Twitter Lite (2017): a 65 percent increase in pages per session, 75 percent more Tweets sent, and a 20 percent drop in bounce rate.
Pinterest (2017): core engagements up 60 percent, user-generated ad revenue up 44 percent, and time spent up 40 percent versus the old mobile web, after cutting time-to-interactive from 23 seconds to 5.6 seconds.
Hulu (around 2020 to 2021): 96 percent of its legacy desktop-app users adopted the PWA within five months, with a 27 percent increase in return visits, per Google's own PWA documentation. This one is newer and worth weighting more heavily.

One caution in the other direction. The often-repeated claim that Starbucks "doubled its daily active users" with its PWA is not something I could confirm at a primary source; the builder's page states only the size figure. I am citing the size difference, which is documented, and flagging the daily-active-users claim as unverified rather than repeating it as fact. That is the right posture for all of these: the pattern is well evidenced, the specific old number is not a guarantee.

The caveats the pitch decks skip, especially on iPhone

Here is where honesty earns trust. PWAs are strong, and they have real gaps, and most of the gaps live on iOS.

Support is broad at the foundation. Service workers, the engine of offline and caching, have about 96 percent global browser support and have shipped in Safari since 2018, so the core of a PWA works almost everywhere. Installability and the manifest are widely supported too, though Safari implements only a subset of the manifest's features.

Push on iPhone is recent and conditional. Web push notifications did not work on iPhone at all until iOS 16.4, which Apple shipped on March 27, 2023. Even now, on iOS a web app can only send push notifications if the user has actually added it to the Home Screen. A site sitting in a Safari tab cannot request or receive push. So the re-engagement story on iOS depends on the user installing your PWA first, which fewer of them will do than on Android, where install prompts are more prominent.

iOS can quietly evict your offline data. Safari's tracking-prevention rules can clear script-writable storage for sites a user has not opened in about seven days, so a PWA's offline cache is less durable on iPhone than on Chrome. Design for it to be re-fetchable, not permanent.

Apple reminded everyone the platform is not fully in your hands. In early 2024, in the iOS 17.4 betas for the European Union, Apple degraded Home Screen web apps to plain bookmarks and, on February 15, 2024, said it would remove Home Screen web app support for EU users, citing the Digital Markets Act. After a loud backlash it reversed course on March 1, 2024, and kept them. PWAs survived, but the episode is a fair reminder that a browser-based app lives partly at the platform vendor's discretion.

Do not chase a "PWA score" that no longer exists. Google's Lighthouse audit removed its dedicated PWA category in version 12.0.0, released April 22, 2024. The current Lighthouse categories are Performance, Accessibility, Best Practices, and SEO. If an old tutorial tells you to get your Lighthouse PWA score to 100, that category is gone; build to the actual capabilities instead.

And push can be a liability, not just an asset. The ability to notify people is only worth having if you use it sparingly. A PWA that nags is a PWA people uninstall.

Discoverability: you get both doors, not neither

One genuine trade is discoverability, and it cuts both ways in your favor if you understand it. A native app is found by browsing an app store but is invisible to Google. A PWA is the reverse by default: because it is a website at a URL, it is indexed by search engines and shareable with a link, which is how most small businesses actually get found. And you are not locked out of the stores. A PWA can be packaged and submitted to Google Play using a Trusted Web Activity, and to the Microsoft Store using PWABuilder, with no rewrite. So the honest framing is not "web instead of store." It is that a PWA gets the search-and-link door for free and can still walk through the store door if you want it.

So should you add one?

Add a PWA when the app-like parts would genuinely help and you do not want to fund a native build. A store or restaurant that wants an installable ordering icon, a publisher that wants readers to keep browsing offline and come back via push, a tool or dashboard people return to daily, a site serving customers on slow or spotty networks: these are the clear yes cases, and the cost is adding a manifest and a service worker to a site you already run.

Be honest about the no cases too. If your business depends on being discovered by browsing an app store, on deep native hardware features Safari does not expose, or on iOS push reaching users who will never bother to install anything, native still wins and a PWA will disappoint you. And a simple brochure site that no one revisits does not need one at all; the manifest and service worker would be effort spent on capabilities no one uses.

For most small businesses, though, the PWA sits in the sweet spot: roughly 80 percent of what people wanted from "an app," for a rounding error of the cost, added to the website they were going to have anyway. If you were handed a five-figure quote to build an app, this is the question to ask first, and often the honest answer is that you can get most of the way there by enhancing what you already own. That is the same argument that runs through The $97 Launch: the expensive version is rarely the one you actually need.

Fact-check notes and sources

Definitions and support come from browser-vendor and standards documentation; case-study metrics come from the companies or Google, and are dated. Where a figure is vendor-reported, old, or unverified, it is flagged.

What a PWA is: the manifest-plus-service-worker-over-HTTPS definition and the "single codebase, multiple platforms" framing are from MDN, Progressive web apps and web.dev, "What are PWAs?" (the Capable, Reliable, Installable pillars).
Browser support: service workers have roughly 96 percent global support (95.59 percent full plus 0.57 percent partial) per caniuse, shipping in Chrome 45 (2015) and Safari 11.1 desktop / iOS 11.3 (2018).
App-store commissions: Apple's standard 30 percent and the 15 percent Small Business Program (from January 1, 2021) are per Apple Newsroom and developer.apple.com; Google Play's 15 percent on the first $1 million and 30 percent above is per Google Play Console Help.
Speed and conversion: Deloitte's "Milliseconds Make Millions" (March 2020) found a 0.1-second mobile speed improvement raised retail conversions 8.4 percent and average order value 9.2 percent (Deloitte); the BBC "10% of users per additional second" figure is cited by web.dev.
Case studies (all vendor-reported, dated): AliExpress +104% new-user conversion (2016) and Twitter Lite +65% pages per session, 600KB vs 23.5MB (2017) are from Google's web.dev case studies; Pinterest +44% ad revenue, TTI 23s to 5.6s (2017) is from Pinterest Engineering; the Starbucks 233KB vs 148MB size is from builder Nearform (the "doubled daily active users" claim is not confirmed at a primary source and is treated as unverified); Trivago's 67% offline continuation (2017) is via Think with Google; Hulu's 96% adoption in five months (around 2020 to 2021) is from web.dev's PWA learning docs.
iOS caveats: web push arrived in iOS/iPadOS 16.4 (public release March 27, 2023) and works only for Home Screen-installed web apps, per the WebKit blog; iOS storage can be evicted for sites unused for about seven days per WebKit tracking prevention.
The 2024 EU episode: Apple said on February 15, 2024, it would remove Home Screen web apps for EU users citing the DMA, then reversed on March 1, 2024, keeping them; see Apple's DMA developer support page.
Lighthouse: the dedicated PWA audit category was removed in Lighthouse v12.0.0 (April 22, 2024); current categories are Performance, Accessibility, Best Practices, and SEO.
Store distribution of PWAs: Google Play via Trusted Web Activity and the Microsoft Store via PWABuilder.

This post is informational and technical, not business or legal advice. Browser capabilities, platform policies, and app-store terms change frequently, and the case-study figures are dated vendor claims, so verify current specifics before making a build decision. Mentions of specific companies and products are nominative fair use, and no affiliation is implied.

Why Add a PWA to Your Site: The Honest Value Case for a Progressive Web App