A client recently sent me a six-year-old Progressive Web App and asked for an audit. Their goal was simple and reasonable: they wanted better offline availability. Their acceptance criterion was less reasonable. They wanted a Lighthouse PWA score of at least 90.
So I opened Lighthouse and ran the report. Here is what came back:
Four rings. Performance, Accessibility, Best Practices, SEO. No PWA.
I had to write back and explain that the number they were asking me to hit doesn't exist. Google removed the PWA category from Lighthouse in version 12, back in April 2024. There is no PWA score to score. It's gone.
That email nagged at me for a week. Not because the client was wrong to want what they wanted — they weren't — but because it made me realize I'd been asking the wrong question. The interesting question in 2026 isn't "is PWA dead?" It's "what happened to PWA over the last six years while everyone stopped paying attention?"
PWA was never a technology. It was a checklist.
Here's the thing worth remembering. "Progressive Web App" was never an API, a framework, or a runtime. The term was coined in 2015 by Frances Berriman and Chrome engineer Alex Russell as a marketing wrapper around capabilities that already existed: a service worker, a web app manifest, and HTTPS. That's it. "PWA" was a name for a bundle, and Lighthouse turned that bundle into a checklist with a green badge at the end of it.
The checklist is what died. And it died in the most literal way possible.
First, in Lighthouse 11 (2023), Chrome dropped the service-worker requirement from its installability criteria — a service worker was no longer needed for a site to be installable, so the check was removed. Then Lighthouse 12 deleted the entire PWA category. The service-worker gatherer, the manifest installability checks, the "PWA optimized" audits — all of it, gone from the report and from PageSpeed Insights.
If you want a headline that says PWA is dead, that's your headline: Google deleted PWA from its own tooling.
But here's the reframe. The category didn't disappear because PWA lost. It disappeared because it won. Installability, offline caching, a manifest, push — these stopped being a special, badge-worthy achievement and became a normal, unremarkable part of the web platform. You don't get a Lighthouse category for "uses HTTPS" either. Nobody writes think-pieces asking if HTTPS is dead. The absence of a score is the signature of a technology that graduated into infrastructure.
The audit was a time capsule
Which brings me back to the six-year-old app on my desk. Built around 2019–2020, it's a perfect fossil of the PWA hype era — the years when everyone was chasing that Lighthouse badge and the "Add to Home Screen" prompt like it was the whole point.
Auditing it, I found two very different kinds of code.
The first kind was the stuff that was built to pass the checklist. Some of it is now pointless — the app bends over backwards to satisfy installability rules that Chrome has since relaxed. It optimized for a test that no longer runs.
The second kind was the stuff that was built as plain infrastructure: the caching layer, the offline handling, the manifest. And that code still works. It's doing its job today, quietly, six years later. More to the point, it's exactly what the client came to me for. They didn't actually want a score of 90. They wanted reliable offline access — which is the oldest, most boring, most durable part of the entire PWA idea.
Then there was the detail I keep thinking about. The manifest was missing an id.
If you've built PWAs recently, you know the id property — it gives an installed app a stable identity that's decoupled from its start_url. But it only landed in Chrome 96, at the end of 2021. This app predates it. The missing id isn't a bug the original developer made. It's a field that didn't exist yet when they shipped.
And the consequence is subtle and real: without an explicit id, the browser derives the app's identity from start_url. Change that URL later and the browser treats it as a brand-new app — a "ghost install" — and the existing users silently stop receiving updates.
Sit with that for a second. A "finished," shipped, six-year-old PWA is quietly out of spec today. Not because it broke. Not because PWA died. But because PWA kept maturing the entire time nobody was looking at it. The spec moved on underneath a static app. That, right there, is the opposite of a dead technology.
Checking all of this by hand — is the manifest complete, is there an id, do the icons actually resolve, does the service worker really control the page, which Fugu APIs does the site touch — got tedious fast. So I built a small tool for it: PWA & Installability Inspector, a Chrome extension that gives any site an installability verdict and flags exactly which manifest properties are missing, id included. It runs entirely locally, it's open source (MIT), and I shipped the first version this week.
Consider it my own small attempt to replace the checklist Lighthouse retired — not with a vanity score, but with actionable fixes.
The frontier moved
So if installability and offline are solved, boring, and done — where did the actual frontier go?
It moved to the hard part: closing the gap between what a web app can do and what a native app can do. That's the whole mission of Project Fugu, the cross-company effort (Google, Microsoft, Intel, Samsung, and others) to bring native-grade capabilities to the web while keeping the web's security and privacy model. File System Access, Web Share, Contact Picker, and a long tail of hardware APIs all came out of that work.
And in 2026 the edge is somewhere the 2020 hype crowd never imagined: on-device AI and the agentic web. WebGPU brings GPU compute to the browser, WebNN handles neural-network inference, and an on-device Prompt API runs models locally. At Google I/O 2026, Chrome unveiled WebMCP — a proposed open standard, developed with Microsoft through the W3C, that lets a site expose structured tools to browser-based AI agents instead of making them scrape the DOM. It's already in an origin trial from Chrome 149, and it can even be driven by that same on-device Prompt API. The conversation has completely shifted. In 2019 the exciting question was "can a web app be installed and work offline?" In 2026 it's "can a web app run a model on-device and drive an agent?"
That's not a technology in decline. That's a technology whose easy problems got solved so thoroughly they became invisible, freeing everyone to fight over the hard ones.
The one wall that didn't move — and it's now a legal story
There's exactly one place where PWA's progress has been genuinely stuck, and you already know its name: Apple and WebKit.
To be fair, iOS has crept forward. Web Push finally arrived in iOS 16.4 in 2023, and the Badging API works. But a whole class of Fugu capabilities — Web Bluetooth, Web NFC, WebUSB, and a set of sensor APIs Apple declined back in 2020 — still don't exist on iOS. On Android a PWA is a first-class citizen; on iOS it's a curated subset, and Apple draws the boundary.
What's genuinely new is where that fight is happening. It's no longer a developer-advocacy fight — it's a regulatory one.
In February 2024, developers discovered that a beta of iOS 17.4 had quietly stripped standalone mode from Home Screen web apps in the EU — installed PWAs would just open as Safari tabs. After roughly three weeks of pressure from developers, Open Web Advocacy, and the European Commission, Apple reversed course and restored the behavior. Since then, iOS technically allows third-party browser engines in the EU through BrowserEngineKit — but the friction is high enough that, as of early 2026, essentially no browser has actually shipped on it. And in October 2025, the UK's Competition and Markets Authority designated Apple with Strategic Market Status over its mobile platform — browsers and browser engines included — and flagged removing the WebKit restriction as a priority for intervention.
Think about how strange that is. The future capabilities of a web technology now partly run through regulators, commissions, and courts, rather than through spec editors and browser release notes. For a piece of the open web, that is a very unusual place to live.
So, is PWA dead?
No. But "alive" is the wrong frame too. What's really happening is two stories braided together.
One is a story about maturity: the term is fading precisely because it won the battles it could win on its own. Offline, installable, push — the boring parts became the web, and boring is what durable infrastructure looks like.
The other is a story about power: the battles PWA couldn't win technically have turned into a legal and regulatory fight over who controls what the web is allowed to do on the device in your pocket.
Which takes me back to that client. I can't give them a PWA score of 90 — the number is gone, and honestly it was always a vanity metric. But I can give them what they actually asked for: a genuinely reliable offline experience, a manifest that won't orphan their users on the next URL change, and an honest picture of what the platform can and can't do on each OS. The score is dead. The work is very much alive.
Maybe that's the real answer to "is PWA dead in 2026." The badge died. The idea just stopped needing a badge.
Auditing an old PWA of your own? Check your manifest for an id first — if it's missing, you're one start_url change away from orphaning every installed user. If you'd rather not check by hand, that's exactly what I built the PWA & Installability Inspector for. Feedback and bug reports welcome — in the comments or on the repo.
Top comments (0)