Because the promise is genuinely good and the delivery has always been uneven. A progressive web app gives you one codebase that installs like an app, works offline, and skips the app stores. The argument continues because what it can do depends heavily on which browser and which operating system your visitor is using.
Founders usually hear about PWAs from a developer who is trying to avoid building two native apps. That instinct is sound. The cost saving is real.
The question is whether your website is the kind of thing anyone would ever install. For a lot of businesses the honest answer is no, and that is the part nobody says out loud.
MDN Web Docs defines it cleanly. A progressive web app is "an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app." It runs from one codebase across devices, and it can be installed, run offline, and integrate with the operating system.
The key word is installed. A PWA is not a website with a fast loading spinner. It is a site that a person can add to their home screen or dock, after which it opens in its own window without browser chrome.
MDN puts the two halves side by side. Like a website, a PWA "can run on multiple platforms and devices from a single codebase." Like a native app, "it can be installed on the device, can operate while offline and in the background, and can integrate with the device and with other installed apps." If you are still deciding between the two routes entirely, we compared them in whether to build a mobile app or a website first.
Three things, and they are less work than people expect. You need HTTPS, a web app manifest describing the app, and in practice a service worker to handle offline behaviour. Chrome adds one more condition that catches teams by surprise: the visitor has to have engaged with the page first.
Chrome's published install criteria are specific. The site must "be served over HTTPS." The manifest needs a short_name or name, a start_url, and icons that "must include a 192px and a 512px icon."
The manifest also needs a display value, which Chrome says "must be one of fullscreen, standalone, minimal-ui, or window-controls-overlay." And prefer_related_applications "must not be present, or be false," because that setting tells the browser to promote a native app instead.
The engagement rule is the sneaky one. Chrome requires that the user has interacted with the page, either by clicking or tapping it at least once or by spending more than thirty seconds on it. You cannot prompt someone to install the moment they land.
They do, with real limits. Apple supports Home Screen web apps on iOS and iPadOS, and since version 16.4 those apps can receive push notifications. The catch is that the person has to add your site to their Home Screen first. A plain Safari tab gets none of it.
The WebKit team announced this in February 2023, in a post by Brady Eidson and Jen Simmons. Web Push on iOS works through the Push API, the Notifications API, and Service Workers together, the same three pieces the rest of the web uses.
The same release added the Badging API, so a Home Screen web app can set the little number on its icon, and support for the id member of the Web Application Manifest so iOS can tell web apps apart reliably.
That Home Screen requirement is the whole ballgame on iPhone. Asking a customer to open a share sheet and tap Add to Home Screen is a big ask. If your product does not earn that, the push notifications never arrive because nobody installed anything.
Run without a network, run in the background, and live outside the browser. A service worker sits between your pages and the network, so it can serve cached content when the connection drops. That is the capability a normal site simply does not have, no matter how fast it loads.
Background work is the second real gain. MDN lists Background Synchronization and Background Fetch as service worker capabilities, which means a queued action can complete after the user has closed the tab.
The third gain is presence. An icon on a home screen gets opened. A bookmark does not. For anything a person uses weekly, that difference compounds.
None of this replaces ordinary performance work. A service worker caching strategy sits on top of good HTTP caching rather than instead of it, and our guide to HTTP caching covers the layer underneath.
Plenty, and the gaps cluster on iOS. Deep hardware access, background location, and many of the newer device APIs are either missing or restricted in Safari. If your product needs those, the web is not where it lives yet.
Discovery is the other honest weakness. Nobody browses a store looking for progressive web apps. You get installs from people who already visit your site, which means a PWA amplifies an audience rather than creating one.
There is also a maintenance cost people underestimate. A service worker caches aggressively by design, so a bad deploy can leave stale files on real devices. We have seen teams ship a fix and wonder for days why customers still see the old version.
For most marketing and content sites, build neither. For tools people use repeatedly, a PWA is usually the better first bet. You avoid the App Store and Google Play review cycles, you ship updates instantly, and you keep one codebase instead of three.
Our rule of thumb is frequency. If someone would open the thing more than once a week, installation earns its keep. If they visit twice a year to check your pricing, it never will.
Ecommerce sits in an interesting middle. Baymard Institute puts the average documented cart abandonment rate at 70.22%, an average it calculated from 50 different studies. Offline resilience and instant repeat loads genuinely help there, though neither fixes a checkout that asks for too much.
The failure mode we see most is building a PWA to avoid fixing a slow site. If the first load is heavy, installing it just gives people a faster route to a bad experience.
Not fully, and the blocker is structural. Webflow's hosting does not let you place a service worker at the root of your domain, and a service worker has to sit at the root to control the whole site. Progressier, a service built specifically to add PWA features to hosted platforms, states plainly that "with Webflow, it's not possible to add a service worker to your PWA."
Progressier's own documentation goes further, noting that "due to the limitations of the platform, it's not possible to install your app as PWA from your own domain." Their workaround is to serve the installable version from a separate domain they control.
You can still add a manifest and icons through custom code in Webflow, which gets you a nicer add to home screen experience. What you do not get is offline support, because that is the service worker's job.
This is one of the few cases where we tell clients that Webflow is the wrong tool for a specific requirement. Everything else we would still build there. If genuine offline behaviour is a hard requirement, the app part needs to live somewhere else, and the marketing site can stay in Webflow.
Not directly, and this is where a lot of bad advice starts. Google indexes your pages the same way whether or not a manifest exists. Installability is not a ranking signal. What can help is the caching and performance work you do along the way, because Core Web Vitals do matter.
There is a real risk on the SEO side too. If your app shell renders content with JavaScript after load, crawlers that do not execute scripts see an empty page. That is a bigger problem now that answer engines read raw HTML.
We build content pages as static HTML for exactly this reason, and layer interactivity on top rather than underneath. Our post on progressive enhancement explains the approach, and static versus server rendered covers when each makes sense.
Build a PWA if people use your product repeatedly and offline access would genuinely help them. Skip it if your site is a brochure, a portfolio, or a lead generation page. The technology is mature enough to trust, but it only pays back when installation makes sense for the person doing the installing.
If you are unsure, the cheap test is to look at your returning visitor numbers. A site where most traffic is first time visitors has nothing to install. A site where the same people come back weekly is a candidate.
Start with the manifest and icons regardless. That part costs an hour, improves how your site looks when someone does save it, and commits you to nothing.
If you want a second opinion on whether your product is a PWA candidate or just a site that needs to be faster, we are happy to talk it through with you. You can reach us at phoenix.studio, and we usually come back to people within a couple of days.
Tell us where you want to go. We'll tell you how we'd get you there.