I’ve noticed more companies investing in Progressive Web Apps again, despite years of limited attention. Are recent improvements in browser support, performance, and offline features driving a real PWA comeback, or is this just a short-lived trend?
Expect a gradual return, not a full PWA takeover. Browser support and offline behavior are better than they were a few years ago, and companies are under more pressure to ship across desktop and mobile without maintaining several separate codebases. For dashboards, retail sites, booking tools, and internal apps, a PWA can now cover most practical needs at a reasonable cost.
The bigger limitation is still user behavior. Many people do not understand browser installation prompts, and PWAs can feel less visible or trustworthy than apps downloaded through a store. Support on Apple devices has improved, but the experience is still less consistent than on Android, especially around background activity, notifications, storage, and OS integration.
So yes, there is a real comeback, but it is mostly pragmatic rather than fashionable. Companies are choosing PWAs where instant access, easier updates, and broad reach matter more than deep device features. Native apps are not being replaced. The middle ground has simply become useful enough again.
Start by measuring how many users actually install it before treating “PWA” as the product strategy. @zeroeagle5572 is right about store visibility, but the quieter shift is that many companies now use PWA features without pushing installation at all. Faster repeat visits, cached screens, and limited offline use can improve a normal web app even if nobody adds it to a home screen. That makes this less of a PWA comeback and more of the web finally absorbing the useful parts.
Calling it a comeback gives PWAs a little too much credit. What has come back is interest in shipping one web codebase and avoiding app-store friction. The technology is more capable now, but companies are still making a business decision first and a platform decision second.
@securedevsync is right that installation is almost beside the point for many products. The more useful question is whether service workers, caching, notifications, and installability make the existing site better without making it harder to maintain. That last bit gets overlooked. Cache bugs can leave users running stale code, offline states need real design work, and testing becomes messy once the app behaves differently depending on browser, device, permissions, and whether it was installed. A PWA is not automatically the cheap version of a native app.
There is another practical problem: the browser vendor still controls the ceiling. If your product depends on reliable background tasks, Bluetooth accessories, advanced media handling, payments, or tight OS integration, a browser update or platform restriction can affect the experience in ways you cannot fully fix. Native development has its own gatekeepers, of course, but browser-based apps often end up caught between both worlds.
So I would call this a narrower correction rather than a comeback. PWAs are finally a sensible default for some web products, especially ones centered on forms, content, accounts, and transactions. They are much less convincing when the install itself, app-store discovery, or hardware access is central to the product. The boring answer is probably the accurate one: companies are using PWA features where they remove friction, then stopping before the browser becomes the bottleneck.
A lot of the supposed comeback is a labeling trick: teams add a manifest, a service worker, and an install button, then announce a PWA initiative. The same work might have been called “improving the mobile site” five years ago. That does not make it pointless, but it does make trend reports look more dramatic than the actual change.
The business case is strongest when users already arrive through a link. Think customer portals, event schedules, field-service tools, restaurant ordering, or software used by employees. Nobody needs to visit an app store, wait for approval, download 150 MB, and accept seven permissions just to check a booking or complete a form. In those cases, installability is a bonus rather than the main event.
I agree with @securedevsync that installation numbers can be a distraction, but I would go further: aggressively pushing installation can make the product worse. People came to the site to do something, not to answer a browser prompt about adding an icon to their home screen. If repeat visits are faster, the current screen survives a bad connection, and authentication does not fall apart after an update, the PWA features are already doing useful work. The badge does not matter.
The less glamorous test is whether the team can maintain all those states. Online, offline, partially cached, expired login, newly deployed version, old service worker, denied notification permission, and installed versus ordinary browser tab. Congratulations, the “single web app” now has several personalities. That is manageable for a focused product, but it is not free simplicity.
So yes, there is renewed interest, but I would not call it a return of PWAs as a grand platform. It is more like companies finally stopped expecting them to defeat native apps and started using them for jobs they are actually good at. Lower the ambition from “replace the app stores” to “make the website less annoying,” and suddenly the technology looks quite healthy.
Offline support stops being a browser feature the moment users can change data. Caching a product page or previously loaded dashboard is fairly straightforward. Letting someone edit a job report, submit an order, or upload a photo during a weak connection creates a synchronization problem that the service worker cannot solve by itself.
You need to decide what happens when the same record changes on another device, an authentication token expires, a queued request is submitted twice, or the backend rejects data created ten minutes earlier. The interface must show whether something is saved locally, confirmed by the server, or permanently failed. Without that work, “works offline” often means “opens offline, but the important button does nothing.”
That is why I slightly disagree with treating the renewed PWA label as mostly marketing. The label can be sloppy, as @shadowwolf2011sync said, but there is a meaningful technical shift when a team starts designing around unreliable networks instead of assuming every request completes immediately. The benefit extends beyond installed apps. Subway tunnels, crowded venues, rural connections, and phones switching between Wi-Fi and cellular all produce temporary failures that ordinary websites tend to handle badly.
Before calling a project a good PWA candidate, I would ask three questions:
- Is offline access read-only, or must users create and edit data?
- Can queued operations safely be retried without duplication?
- Can the app recover when its cached frontend and the deployed backend are on different versions?
If the answers are unclear, adding installability first is backwards. Build a resilient web app, then add the manifest, icons, notifications, and installation flow if users have a reason to keep it.
So yes, PWAs are making a modest comeback, but I think connection resilience is a better sign than installation counts. A home-screen icon is cosmetic. An app that survives a dropped connection without losing work has become materially better, regardless of whether anyone calls it a PWA.
Picture two setups that both claim offline support. A retail site caches its catalog and a few product images so browsing survives a dead spot. A field-service tool queues job reports and photo uploads while the tech is in a basement with no signal. The first one loses nothing if the cache gets wiped. The second one can silently lose a day of work, and that difference is the whole game.
That’s where I’d add a caveat to @dave_tech, who otherwise nailed the important shift. Connection resilience is the right thing to chase, but the browser can pull the rug out from under it. Storage isn’t guaranteed. When a device runs low on disk, or the user hasn’t touched the site in a while, browsers can evict your cached data and IndexedDB contents. iOS has been especially rough here, with tighter caps and a history of clearing storage for sites that aren’t installed and haven’t been visited for a stretch. So your beautifully designed offline queue can just not be there when the tech reopens the app. If people are creating data offline, you either request persistent storage and handle the case where it’s denied, or you accept that the queue is fragile and design the UI to scream about unsynced work.
I mostly agree with @shadowwolf2011sync that a lot of the ‘comeback’ is relabeling, but I think that framing undersells one real change. Teams are finally treating the network as unreliable by default instead of a happy path with an error toast bolted on. That’s a genuine engineering habit shift, not just a manifest and an install button. The label is marketing. The mindset isn’t.
The overlooked comparison for me is update behavior versus offline behavior, because they fight each other. Aggressive caching makes repeat visits fast but risks users running stale code after a deploy. Aggressive freshness kills the offline benefit. Every PWA team ends up picking a point on that spectrum whether they mean to or not, and getting it wrong shows up as weird bugs that only reproduce on someone’s phone that hasn’t refreshed the service worker in three weeks.
So yes, modest comeback, real one, but I’d judge a project less by whether it works offline and more by whether the team has actually decided what happens when the cache gets evicted and when a new version ships. Skip those two and you don’t have a resilient app, you have a demo that happens to load without wifi.
Pull your traffic sources for the last quarter before you commit to any of this. If most of your users land through search, a shared link, or an email, that alone tells you the web app is doing something a native app struggles with, and it reframes the whole ‘comeback’ question.
That’s the angle I think everyone here skipped. The offline and caching debate between @dave_tech and @mega_phantom_proxy is solid, and honestly it’s the most useful part of the thread, but it treats the PWA as an engineering artifact. The reason companies keep drifting back is dumber than that. A web app has a URL. You can text it, paste it into Slack, hand it to a customer, and it opens the exact screen you meant. Search engines crawl it. A native app is a black box by comparison, and every ‘deep link’ into it is extra plumbing that breaks in fun ways. For anything built around content, listings, or a shareable state, that’s not a nice-to-have, it’s the actual business case, and it survives no matter how many people ignore the install prompt.
Where I’d push back a little is on the framing that installation counts are basically noise. @securedevsync and @shadowwolf2011sync are right that chasing installs can hurt the product, but there’s a middle position they skip. On Android, an installed PWA changes how the OS treats your storage and background behavior, which loops straight back into the eviction problem @mega_phantom_proxy raised. So installs aren’t the trophy, but for a field-service tool that queues real data, getting the user to install can be the difference between the browser keeping your IndexedDB and quietly wiping it. Same feature, completely different reliability depending on install state. That’s worth measuring even if you never advertise it.
The thing people forget when they run the cost comparison is that a PWA doesn’t get you off the platform treadmill, it just moves it. You skip App Store review, sure, but now every Safari release and every Chromium change is your release schedule too, and you don’t control the date. So my rough decision rule is this. If the product lives and dies by being found and shared, lean web. If it lives and dies by hardware access or offline durability, be honest that the browser is a partner you can’t fully trust and budget for the workarounds. Most teams sit somewhere in between and end up with a resilient web app that happens to have a manifest, which is fine. Just don’t call the manifest the strategy.