The History and Evolution of Progressive Web Apps¶

Progressive Web Apps are the result of nearly two decades of attempts to make web technology a first-class way to build installable, offline-capable applications. Most of those attempts failed (Google Gears, the HTML5 Application Cache, Chrome Apps, Firefox OS), and the reasons they failed directly shaped today's design: low-level primitives instead of declarative magic, the same URL for the site and the app, progressive enhancement instead of a separate app platform. This page walks through that history chronologically, from the iPhone's 2007 "sweet solution" to the 2026 debate over the Web Install API, explaining the technical significance of each step.

The timeline at a glance¶

flowchart TD
    subgraph E1["2007 to 2012: first wave"]
        A1["2007: iPhone web apps, Google Gears"]
        A2["2008: web clips and apple-mobile-web-app-capable"]
        A3["2009 to 2010: AppCache ships in Firefox, Safari, Chrome"]
        A4["2012: Application Cache is a Douchebag"]
    end
    subgraph E2["2010 to 2016: platform detours"]
        B1["2010: Chrome Web Store hosted apps"]
        B2["2012: Windows 8 HTML and JS apps"]
        B3["2013: Chrome packaged apps, Firefox OS phones"]
        B4["2015: Windows 10 Hosted Web Apps"]
    end
    subgraph E3["2013 to 2016: new primitives and a name"]
        C1["2013: NavigationController, manifest draft"]
        C2["2014: Service Workers first public draft"]
        C3["2015: Chrome 40 ships service workers"]
        C4["June 2015: Progressive Web Apps essay"]
        C5["Nov 2015: Flipkart Lite"]
    end
    subgraph E4["2017 to 2023: every engine joins"]
        D1["2017: WebAPKs, Twitter Lite"]
        D2["2018: Safari 11.1, EdgeHTML 17, desktop PWAs, Fugu"]
        D3["2019: Trusted Web Activity"]
        D4["2020: Chromium Edge"]
        D5["2022: Web Push in Safari on macOS"]
        D6["2023: iOS 16.4 web push, macOS Add to Dock"]
    end
    subgraph E5["2024 to 2026: redefinition"]
        F1["2024: DMA episode, Lighthouse 12"]
        F2["2025: Declarative Web Push, iOS 26, Firefox 143"]
        F3["2026: Web Install API and install element"]
    end
    E1 --> E2 --> E3 --> E4 --> E5

Before PWAs: the first wave (2007–2012)¶

2007: the iPhone's "sweet solution"¶

When Apple introduced the iPhone in January 2007, it had no third-party app platform. At WWDC on June 11, 2007, Steve Jobs announced that developers could build apps for the iPhone using web technology: full Safari, "Web 2.0" and AJAX. He described it as "a very sweet solution": web apps that "look and behave exactly like apps," could integrate with iPhone services (make a call, send an email, look up a location in Google Maps), and needed no SDK or review.

Developers were not persuaded. The first iPhone web apps had no offline storage, no home screen presence, no access to the camera or accelerometer, and ran inside a browser tab on a 2G (EDGE) connection. Apple announced a native SDK in October 2007, and the App Store launched with iPhone OS 2.0 on July 10, 2008. For the next decade, "web app vs native app" became the defining mobile debate.

Technically, however, 2007 established the idea that a web page could be a mobile app if the browser gave it the right hooks, and Apple added those hooks one by one:

• iPhone OS 1.1.3 (January 2008) added web clips: "Add to Home Screen" in Safari created a home screen icon for any page.
• iPhone OS 2.1 (2008) added the apple-mobile-web-app-capable meta tag, which made a web clip open in full-screen mode without Safari's UI, together with apple-mobile-web-app-status-bar-style and the window.navigator.standalone property to detect that mode.

A typical 2008-era iPhone web app head looked like this, and variations of it survived on the web for more than fifteen years:

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">
<!-- Open from the Home Screen without Safari UI (iPhone OS 2.1+) -->
<meta name="apple-mobile-web-app-capable" content="yes">
<!-- default | black | black-translucent -->
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<script>
  // Non-standard, iOS-only: true when launched from a Home Screen web clip in full-screen mode.
  if (window.navigator.standalone) {
    document.documentElement.className += " standalone";
  }
</script>

The significance: Apple's model (a user-initiated "Add to Home Screen", per-app full-screen mode, no store) is the direct ancestor of today's iOS Home Screen web apps. Safari 26 finally made the meta tag unnecessary by opening every site added to the Home Screen as a web app, 17 years later.

2007: Google Gears¶

Google announced Gears (initially "Google Gears") at its Developer Day on May 31, 2007: an open-source browser plug-in that added offline capabilities to Firefox, Internet Explorer and later Safari and Chrome. It provided several modules:

• LocalServer, which cached and served resources locally, enabling offline page loads;
• Database, a SQLite database exposed to JavaScript;
• WorkerPool, background JavaScript execution in parallel threads (years before Web Workers were standardized);
• Desktop, for creating desktop shortcuts and other OS interactions;
• Geolocation, for locating the user.

Gmail, Google Docs, Google Reader and others used Gears for offline modes, and third-party sites such as WordPress adopted it. But a plug-in cannot be a platform: it required installation, lagged behind browser releases and was controlled by one company. Google announced in February 2010 that there would be no further development, in favor of the HTML5 standards that Gears had helped inspire (Web Storage, Web SQL Database, Web Workers, Geolocation and Application Cache). Gears was removed from Chrome in June 2011, and Google's own apps dropped it by December 2011.

The significance: Gears proved that offline web apps needed three things, which are exactly the three things PWAs use today: a programmable resource cache, a client-side database and background threads.

2009–2010: the HTML5 Application Cache¶

The WHATWG's HTML5 work included an offline web applications feature, universally known as Application Cache or AppCache. It shipped in Firefox 3.5 and Safari 4 (both June 2009), then in Chrome and iOS Safari; caniuse lists support from Chrome 4, Firefox 3.5, Safari 4 and iOS Safari 3.2. It was the first standard way to make a page work offline.

AppCache was declarative. You pointed the manifest attribute of the <html> element at a text file that listed what to cache, what always required the network and what to show when a request failed:

<!doctype html>
<html manifest="/offline.appcache">

CACHE MANIFEST
# v12 2012-05-08  <- changing this comment was the only way to trigger an update

CACHE:
/css/app.css
/js/app.js
/img/logo.png

NETWORK:
*

FALLBACK:
/ /offline.html

// The browser downloaded a new cache in the background; the page is still running
// on the old one until you swap and reload.
window.applicationCache.addEventListener("updateready", () => {
  if (window.applicationCache.status === window.applicationCache.UPDATEREADY) {
    window.applicationCache.swapCache();
    window.location.reload();
  }
});

It looked simple. In practice it was a trap.

Why AppCache failed¶

On May 8, 2012, Jake Archibald published Application Cache is a Douchebag in A List Apart, a catalogue of "gotchas" that became the standard explanation of why AppCache could not be used safely. The most important ones:

1. Files always come from the ApplicationCache, even if you are online. A cached page was always served from the cache first; the browser only checked for an update after the page had loaded, so users saw the old version and needed a second reload to see the new one.
2. The ApplicationCache only updates if the manifest itself changes. Changing app.js did nothing unless the manifest file's bytes changed, hence the ubiquitous version comment.
3. The ApplicationCache is an additional cache, not an alternative one. When the manifest did change, the browser re-downloaded listed resources through the normal HTTP cache, so long-cached assets could be re-cached in their old versions.
4. Never far-future cache the manifest. If the manifest itself was HTTP-cached, the browser never saw the update, and because pages were served from AppCache you could not even ship a fix to change its URL.
5. Non-cached resources will not load on a cached page unless you remembered the NETWORK: * wildcard.
6. You cannot tell why you ended up on the fallback page: offline, server error, or a missing resource all looked the same.

Worse, any page that referenced the manifest (a "master entry") was implicitly cached, so a multi-page site quickly filled the cache with every HTML page the user had visited, each frozen at the version first seen, with no way to remove them selectively.

The underlying design error was that AppCache encoded one caching strategy (cache first, update in the background, atomically swap on reload) and gave developers no way to express any other. When the built-in strategy did not fit, and it rarely did, there was no escape hatch.

AppCache was then deprecated and removed:

The significance: AppCache's failure is the single most important influence on the service worker's design. Service workers are deliberately low-level: instead of a declarative manifest, you get a programmable proxy (the fetch event) and a storage primitive (the Cache API), and you write the strategy yourself. The lesson took another decade to come full circle: Chrome's Static Routing API (Chrome 123, 2024) reintroduced declarative routing, but only as an optional optimization on top of the programmable model.

Platform detours: web tech as a separate app platform (2010–2016)¶

While standards bodies worked on AppCache, several vendors took a different route: package web technology into a separate app platform, with its own manifests, stores and privileged APIs. All of them are gone or in end-of-life today, but they left lasting marks.

Chrome Apps and the Chrome Web Store (2010–2028)¶

Google launched the Chrome Web Store with hosted apps (essentially a manifest pointing at a website, plus an icon in Chrome's new tab page) in December 2010. On September 5, 2013 it launched a "new breed" of Chrome packaged apps: HTML, CSS and JavaScript bundled into a signed package that ran outside the browser window, offline by default, with access to powerful chrome.* APIs including raw TCP/UDP sockets, USB, serial ports, Bluetooth and the local file system.

{
  "manifest_version": 2,
  "name": "Serial Terminal",
  "version": "1.0",
  "app": {
    "background": { "scripts": ["background.js"] }
  },
  "permissions": ["serial", "storage"],
  "icons": { "128": "icon-128.png" }
}

// Chrome Apps had no URL and no tab: an event page opened native-looking windows.
chrome.app.runtime.onLaunched.addListener(() => {
  chrome.app.window.create("index.html", {
    id: "main",
    outerBounds: { width: 900, height: 600 },
  });
});

Packaged apps enforced a strict Content Security Policy (no eval, no inline scripts) and had no URLs, so they could not be linked, indexed or shared; they were Chrome-only; and they required a store. Google announced on August 19, 2016 that Chrome Apps would be phased out on Windows, macOS and Linux. The timeline slipped while desktop PWAs matured: a revised plan published in January 2020 set June 2022 as the end of Chrome App support on Windows, macOS and Linux. On ChromeOS, Google extended support for Enterprise and Education customers in October 2021 "until at least January 2025", and its current documentation says Chrome Apps in kiosk mode lose support after April 2027 and all remaining Chrome Apps in managed environments reach end of life in October 2028.

The significance: many of today's Project Fugu APIs (Web Serial, WebUSB, Web Bluetooth, File System Access, and the socket APIs now reserved for Isolated Web Apps) are standards-track descendants of capabilities that first existed as chrome.* APIs, redesigned around web permissions instead of install-time manifests.

Firefox OS and Open Web Apps (2011–2016)¶

Mozilla announced Boot to Gecko on July 25, 2011: a complete mobile operating system whose apps were web apps. It shipped as Firefox OS on the ZTE Open, launched in Spain through Telefónica in July 2013. Apps were described by a manifest.webapp JSON file and came in four types: hosted (a website), packaged (a signed zip), privileged (packaged apps with access to sensitive APIs after review) and certified (system apps). Distribution ran through the Firefox Marketplace, and hosted apps could be installed from any page with navigator.mozApps.install().

{
  "name": "Offline Maps",
  "description": "Maps that work without a connection",
  "launch_path": "/index.html",
  "type": "privileged",
  "icons": { "128": "/img/icon-128.png" },
  "developer": { "name": "Example Corp", "url": "https://example.com" },
  "permissions": {
    "systemXHR": { "description": "Download map tiles from any server" }
  }
}

Firefox OS phones targeted low-cost markets but never gained traction against Android. On December 8, 2015 Mozilla announced it would stop selling Firefox OS smartphones through carriers, and in September 2016 it ended all work on the OS. A fork, KaiOS, went on to success on feature phones.

The significance: Firefox OS was the most complete attempt to make the web the app platform, and its manifest work fed directly into the W3C standard. The first public working draft of what became the Web Application Manifest, Manifest for web apps and bookmarks (December 2013), was edited by Marcos Cáceres (then at Mozilla) with Anssi Kostiainen and Kenneth Rohde Christiansen (Intel).

Windows 8 and Windows 10 web apps (2012–2018)¶

Windows 8 (October 2012) let developers build Windows Store apps in HTML, CSS and JavaScript using the WinJS library, with direct access to the Windows Runtime APIs. These were packaged apps, not websites, and they ran only on Windows.

Windows 10 went further with Hosted Web Apps (codenamed Project Westminster, announced at Build 2015): a Universal Windows App whose package contained little more than a start URL, loading a live website that could call Windows Runtime APIs from JavaScript and be updated without resubmitting to the store. Hosted Web Apps were effectively PWAs with a proprietary manifest, and Microsoft's subsequent PWA strategy grew out of them.

What the detours taught¶

The pattern is clear. Approaches that created a separate kind of app (no URL, one vendor, a store) did not survive. PWAs succeeded by refusing to be separate: the installed app is the website.

The primitives arrive (2013–2015)¶

The Extensible Web Manifesto (June 2013)¶

In June 2013 a group of standards contributors, including Alex Russell, Yehuda Katz and others, published The Extensible Web Manifesto. Its core argument was that browsers should prioritize low-level, efficient, secure primitives that developers can build on, and only then standardize high-level features based on what developers actually built. AppCache was the canonical example of getting this backwards. The service worker was the manifesto's flagship application.

NavigationController becomes the service worker (2013–2014)¶

The service worker began in early 2013 as NavigationController, a proposal from Alex Russell to let developers intercept navigations and requests with their own code. The repository's initial commit is dated February 7, 2013, and the early API hung off navigator.controller. On September 11–13, 2013 the design was renamed EventWorker, and on September 17, 2013 it became ServiceWorker, reflecting that the worker handled many kinds of events, not just navigations. Jake Archibald, who had documented AppCache's failures, joined the effort and later became a co-editor.

The team deliberately chose a low-level API over declarative shortcuts. When the First Public Working Draft of Service Workers was published by the W3C on May 8, 2014, Archibald described it as a collaboration between Google, Samsung, Mozilla and others, and explained that the low-level design was a direct response to AppCache, whose simplified model had proved inflexible and impossible to debug. The draft already contained the architecture still used today:

• a worker registered for a scope, which controls pages rather than being controlled by them;
• install, activate and fetch events;
• event.respondWith() to answer requests programmatically;
• the Cache API, a request/response store separate from the HTTP cache;
• an HTTPS requirement, because a worker that intercepts every request is a perfect man-in-the-middle payload.

The specification reached Candidate Recommendation on November 19, 2019 and is still maintained as a W3C Candidate Recommendation Draft (the latest published on September 17, 2026), with editors from Google and Microsoft.

The Web App Manifest (2013–present)¶

The first public working draft of Manifest for web apps and bookmarks was published on December 17, 2013. It consolidated the scattered metadata that platforms had invented (Apple's meta tags, Microsoft's tile meta tags, Chrome's hosted app manifests, Firefox OS's manifest.webapp) into a single JSON file linked from the page: name, icons, start URL, display mode, orientation.

Chrome 39 (November 2014) used the manifest for "Add to Home Screen" on Android. The document became the Web Application Manifest, published by the W3C Web Applications Working Group; as of August 2026 it is still a Working Draft (edited by Marcos Cáceres of Apple, Daniel Murphy of Google and Christian Liebel of Thinktecture), even though its core members have shipped in every engine.

January 2015: Chrome 40 ships service workers¶

Service workers shipped in Chrome 40, promoted to the stable channel in January 2015. It was the first time a browser gave developers a programmable network proxy and a scriptable cache under their own control.

April 2015: Chrome 42 adds push and install banners¶

Chrome 42 (April 2015) added the two features that turned "offline website" into "app":

• the Push API and Notifications API in service workers, delivered at first through Google Cloud Messaging (the manifest needed a proprietary gcm_sender_id until the standard VAPID mechanism replaced it in 2016); and
• app install banners on Android: when a site had a manifest, was served over HTTPS and had a service worker, and the user visited it with some frequency, Chrome prompted to add it to the home screen.

The install banner criteria (manifest + HTTPS + service worker + engagement) became the de facto definition of a PWA for the next eight years.

Naming the idea (2015–2016)¶

June 15, 2015: "Escaping Tabs Without Losing Our Soul"¶

With service workers, manifests, push and install banners all shipping in Chrome, Alex Russell published Progressive Web Apps: Escaping Tabs Without Losing Our Soul on his blog on June 15, 2015. He and designer Frances Berriman had "enumerated the attributes of this new class of applications" over dinner the night before; Berriman had called them "Progressive Open Web Apps" and they settled on "Progressive Apps".

The essay listed nine attributes (responsive, connectivity independent, app-like interactions, fresh, safe, discoverable, re-engageable, installable, linkable) and described progressive apps as "just websites that took all the right vitamins." A tenth attribute, "progressive", was added in Addy Osmani's Getting started with Progressive Web Apps on December 15, 2015. The What Is a PWA? page explains each attribute technically.

The name mattered. Service workers and manifests were plumbing; "Progressive Web App" gave product managers and executives a concept they could fund, and gave developers a checklist.

November 2015: Flipkart Lite and Chrome Dev Summit¶

Flipkart, one of India's largest e-commerce companies, had shut down its mobile website in 2015 to pursue an app-only strategy. It returned to the mobile web with Flipkart Lite, launched in November 2015 and generally cited as the first major production PWA. Its team presented the architecture at Chrome Dev Summit 2015 (November 17–18), where PWAs were the central theme. The web.dev case study reports that time on site rose to 3.5 minutes versus 70 seconds on the previous mobile experience, with a 40% higher re-engagement rate, 70% greater conversion among users arriving via Add to Homescreen and 3x lower data usage.

2016: the ecosystem forms¶

• January 2016: Firefox 44 shipped service workers and the Push API, making PWAs a multi-engine reality on desktop and Android.
• 2016: Samsung Internet 4.0 added service workers, Web Push and Web App Manifest support, bringing PWAs to the default browser on Samsung devices.
• 2016: Google released Lighthouse, an open-source auditing tool that began as a PWA validator and grew into the performance, accessibility and SEO auditor built into Chrome DevTools.
• May 2016: Google I/O featured PWAs prominently, and in June 2016 Google ran a dedicated Progressive Web App Dev Summit in Amsterdam.
• August 2016: Google announced the Chrome Apps phase-out on desktop, signaling that the web platform itself, not a Chrome-specific app model, was the future.
• 2016: Chrome added support for the standard VAPID authentication scheme for Web Push, removing the dependency on proprietary GCM sender IDs.

Going mainstream (2017–2019)¶

2017: WebAPKs and Twitter Lite¶

The Chrome 57 beta (February 2017) introduced the "improved Add to Home screen": instead of a shortcut, Chrome generated and installed a real Android package, a WebAPK, so that installed PWAs appeared in the app drawer and Android settings and could register intent filters to open their URLs. WebAPKs rolled out to stable users during 2017 and remain how Chrome (and Samsung Internet) install PWAs on Android devices with Google Play services.

In April 2017 Twitter launched Twitter Lite as its default mobile web experience worldwide. The web.dev case study reports a 65% increase in pages per session, 75% more Tweets sent and a 20% lower bounce rate, and notes that the PWA needed about 600 KB over the wire versus 23.5 MB to install the native Android app. Twitter Lite, along with Flipkart, became the reference case study for the next several years.

2018: Safari and Edge ship service workers¶

Safari 11.1, released with macOS High Sierra 10.13.4 and iOS 11.3 at the end of March 2018, shipped service workers and the Cache API, along with basic Web App Manifest support on iOS. WebKit had announced the implementation in a February 7, 2018 blog post, Workers at Your Service, during the iOS 11.3 beta, noting that service workers were partitioned by top-level origin to prevent cross-site tracking. Apple did not promote "PWAs" as such, and important pieces were missing (no push, no install prompt, storage isolated per web app), but every major engine now supported the core PWA primitives.

Microsoft went much further. On February 6, 2018 the Microsoft Edge team published Welcoming Progressive Web Apps to Microsoft Edge and Windows 10, announcing that EdgeHTML 17 had service workers and push enabled, and that PWAs would be first-class apps on Windows, distributable through the Microsoft Store. Both shipped with the Windows 10 April 2018 Update. The Microsoft Store became the first major OS app store to accept PWAs.

2018–2019: desktop PWAs in Chrome¶

Chrome brought installable PWAs to desktop in stages:

Installed desktop PWAs ran in their own windows, appeared in the Start menu, Dock or launcher, and replaced Chrome Apps as Google's recommended desktop app model.

In parallel, Chrome reworked how installation was promoted. Chrome 68 (July 2018) stopped showing the automatic Android install banner and replaced it with a smaller "mini-infobar", while making the beforeinstallprompt event the developer-controlled way to offer installation. Chrome 76 (July 2019) added an install button to the desktop address bar and let developers suppress the mobile mini-infobar by calling preventDefault() on beforeinstallprompt. The patterns that grew out of this are described in Install Prompts & Custom UI.

2018: Project Fugu¶

In November 2018, Google announced the Web Capabilities project, better known by its codename Project Fugu (after the pufferfish that is a delicacy when prepared correctly and dangerous when not). Google, Microsoft and Intel committed to closing the capability gap between web and native apps through open, standards-track APIs designed with security, privacy and user consent in mind. Over the following years Fugu delivered, among others, the Async Clipboard API, Web Share and Web Share Target, the Badging API, File System Access (Chrome 86, October 2020), File Handling, Web Serial and WebHID (both Chrome 89), Window Controls Overlay, the Contact Picker, Screen Wake Lock, Web NFC, Local Font Access and many more.

Fugu also exposed the fault line that still defines PWA capability support: Mozilla and Apple consider several of these APIs harmful to privacy or security and have declined to implement them. The Device & OS Integration section labels each API accordingly.

2019: Trusted Web Activity¶

Chrome 72 (early 2019) introduced Trusted Web Activity (TWA): a way for an Android app to open a verified website full-screen in the user's browser, without browser UI, using a protocol based on Custom Tabs. Ownership is proven with Digital Asset Links, so only the site's owner can publish a TWA for it. TWAs made it practical to publish PWAs in Google Play, and tools such as Bubblewrap and PWABuilder grew up around them. See Trusted Web Activity.

Consolidation (2020–2022)¶

January 2020: Chromium-based Microsoft Edge¶

On January 15, 2020 Microsoft released Edge 79, the first stable version of Edge built on Chromium. EdgeHTML-based PWAs gave way to Chromium PWAs, and Microsoft became one of the largest contributors to Chromium's PWA and Fugu work (Window Controls Overlay, protocol handling, and later the Web Install API originated partly or wholly at Microsoft).

March 2020: Safari's 7-day storage cap¶

On March 24, 2020 WebKit extended Intelligent Tracking Prevention so that all script-writable storage of a website (IndexedDB, LocalStorage, SessionStorage, media keys and service worker registrations and their caches) is deleted after seven days of Safari use without user interaction on that site. After developer concern that this would break offline web apps, WebKit clarified that "web applications added to the home screen are not part of Safari and thus have their own counter of days of use," which matches actual use of the app. The episode made clear that installing a web app on iOS changes how its storage is treated.

2020–2022: legacy removal¶

• August 2020: Chrome 85 removed AppCache by default; December 2020: Firefox 84 removed it; September 2021: Safari 15 removed it.
• February 2021: Firefox 86 removed its experimental desktop "Site Specific Browser" feature, citing little perceived user benefit and known bugs. Mozilla continued supporting installable web apps on Android, and desktop Firefox had no web app support until 2025.
• June 2022: Chrome Apps stopped being supported on Windows, macOS and Linux.

October 2022: Web Push in Safari on macOS¶

At WWDC in June 2022 Apple announced Web Push for Safari, using the same standard Push API, Notifications API and service workers as other browsers (Safari had offered a proprietary "Safari Push Notifications" mechanism on macOS since 2013). It shipped in Safari 16.1 on macOS Ventura on October 24, 2022; a new webpushd daemon relays subscriptions to the Apple Push Notification service, so Safari does not need to be running to receive a push. Apple also announced that Web Push would come to iOS and iPadOS in 2023.

2022–2023: Chrome relaxes the install criteria¶

Chrome had required a service worker with a fetch handler (originally intended as a proxy for "works offline") before a site was installable. Developers routinely satisfied it with an empty fetch listener, which added service worker startup cost without any offline benefit. Chrome removed the requirement for installation from the menu in Chrome 108 on Android and Chrome 112 on desktop, and began showing a default offline page for installed apps without their own. At that point the automatic install prompt still required a fetch handler; current Chromium's promotion pipeline has no service worker check at all. The manifest requirements (name, an icon of at least 144 px, start_url, an app-like display value) remained. See Installability Criteria.

Apple opens up (2023)¶

iOS and iPadOS 16.4¶

On February 16, 2023 WebKit announced, and on March 27, 2023 Apple shipped, iOS and iPadOS 16.4 with the largest set of web app features in iOS history:

• Web Push for Home Screen web apps, using the standard Push API, Notifications API and service workers, integrated with Notification Center, the Lock Screen, Apple Watch and Focus modes. Permission must be requested in response to a user gesture, and only from an app added to the Home Screen.
• The Badging API (navigator.setAppBadge()), so web apps can show a count on their Home Screen icon.
• Support for the manifest id member, so a web app has a stable identity (used, for example, to sync Focus settings across devices).
• Add to Home Screen from third-party browsers: other iOS browsers can now offer the action from their Share menu. The resulting web app still runs on WebKit.

macOS Sonoma: Add to Dock¶

Safari 17 with macOS Sonoma (released in September 2023) let users add any website to the Dock via File > Add to Dock. Web apps open in their own window, support Web Push and badging, integrate with Stage Manager, Mission Control and AutoFill, and do not require a manifest or a service worker (a manifest customizes name, icon, display mode, theme color and start URL). When a web app is created, Safari copies the site's cookies into it so the user stays logged in; after that, no data is shared between Safari and the web app.

The significance: for the first time, Apple shipped desktop web apps, and it chose a model with no installability criteria at all. That choice foreshadowed iOS 26.

Turbulence and redefinition (2024)¶

February–March 2024: the EU Digital Markets Act episode¶

The EU's Digital Markets Act (DMA) required Apple to allow alternative browser engines on iOS in the EU. In the betas of iOS 17.4 (early 2024), users in the EU reported that Home Screen web apps no longer opened as standalone apps: they had been downgraded to shortcuts that opened in the default browser, without their separate storage or push notifications.

On February 15, 2024 Apple confirmed the change was intentional. It explained that under the DMA it could not offer Home Screen web apps only through WebKit, and that supporting them with alternative engines would require an "entirely new integration architecture that does not currently exist in iOS," which it said was "not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps." Developer groups, notably Open Web Advocacy, campaigned against the removal, and the European Commission began asking questions.

On March 1, 2024 Apple reversed course, stating that it would "continue to offer the existing Home Screen web apps capability in the EU," built on WebKit and its security architecture regardless of which browser added them. iOS 17.4 shipped on March 5, 2024 with Home Screen web apps intact.

The significance: the episode demonstrated how fragile platform support for PWAs can be, and that the browser engine running an installed web app is as much a regulatory question as a technical one. iOS & iPadOS covers the current EU-specific details.

March 2024: the declarative router returns¶

Chrome 123 shipped the Service Worker Static Routing API. A service worker can call event.addRoutes() during install to declare that requests matching certain conditions go straight to the network, to Cache Storage, or to a race between the network and the fetch handler, so the browser can skip starting the worker for them. Declarative routing had been discussed for years (Jake Archibald opened a "Declarative routing" issue on the spec repository in December 2018); it arrived once real-world patterns were clear, and as an optimization on top of the programmable model rather than a replacement for it. See Static Routing API.

April–May 2024: Lighthouse 12 drops the PWA category¶

Lighthouse 12.0, released on April 22, 2024 and rolled out to PageSpeed Insights in May 2024 and to Chrome DevTools in Chrome 126, removed the PWA category. The release notes explained that "as per Chrome's updated Installability Criteria, Lighthouse has removed the PWA category." The old checklist (service worker with fetch handler, offline start URL, and so on) no longer matched what Chrome actually required, and a pass/fail "PWA badge" had become misleading. Chrome directed developers to the DevTools Application panel for installability debugging instead. See Lighthouse & Auditing.

Many commentators read the removal as Google abandoning PWAs; in reality it reflected that the definition of an installable web app had become broader and less checklist-driven.

August 2024: "Install page as app" in Chrome¶

From Chrome 128, the desktop menu item Cast, save, and share > Install page as app lets users install any page as an app, even one that does not meet the installability criteria, while Create shortcut now creates a plain bookmark-style shortcut that opens in a browser tab. On Android the equivalent lives under Add to home screen > Install. Chrome, like Safari, was moving toward "any site can be an app; the manifest makes it a good one."

Recent developments (2025–2026)¶

March–May 2025: Declarative Web Push¶

On March 27, 2025 WebKit introduced Declarative Web Push, and Safari 18.4 shipped it on iOS and iPadOS 18.4 for Home Screen web apps (March 31, 2025); Safari 18.5 on macOS followed in May 2025. A push message in a standardized JSON format is displayed by the browser directly, with no service worker code required:

{
  "web_push": 8030,
  "notification": {
    "title": "Webkit.org — Meet Declarative Web Push",
    "lang": "en-US",
    "dir": "ltr",
    "body": "Send push notifications without JavaScript or service worker!",
    "navigate": "https://webkit.org/blog/16535/meet-declarative-web-push/",
    "silent": false,
    "app_badge": "1"
  }
}

The web_push: 8030 key (a nod to RFC 8030, Generic Event Delivery Using HTTP Push) opts the message into declarative handling; notification.title and notification.navigate are required. Subscriptions are created with window.pushManager rather than through a service worker registration, so they survive if Intelligent Tracking Prevention or the user removes the service worker. If a service worker is installed, it still receives a push event and may replace the proposed notification; if it fails to do so in time, the declarative notification is shown as a fallback. Because a notification is always displayed, silent-push penalties do not apply. Messages in this format remain compatible with browsers that only support classic Web Push, as long as your service worker parses the same JSON. See Web Push on iOS & Safari.

September 2025: iOS 26 makes every Home Screen site a web app¶

Announced at WWDC on June 9, 2025 and shipped with Safari 26 on September 15, 2025, iOS and iPadOS 26 changed the default behavior of Add to Home Screen: "by default, every website added to the Home Screen opens as a web app." Previously a site needed apple-mobile-web-app-capable or a manifest with an appropriate display value, a rule that had stood for 17 years. Users can turn off Open as Web App to create a bookmark that opens in their default browser instead. WebKit summarized it as "there are now zero requirements for 'installability' in Safari," while noting that a manifest and service workers still improve the experience. Combined with Add to Dock on macOS, Apple's platforms now treat installation as a purely user-initiated decision.

September 2025: Firefox returns to desktop web apps¶

Firefox 143, released on September 16, 2025, added support on Windows for "running websites as web apps pinned directly to the taskbar," opening in simplified windows while keeping access to installed add-ons. The Microsoft Store build of Firefox gained the feature in Firefox 150. It was the first desktop web app support in Firefox since the Site Specific Browser experiment was removed in 2021. On Linux the feature exists but is disabled by default behind the browser.taskbarTabs.enabled preference; macOS has no equivalent.

November 2025–2026: the Web Install API and the <install> element¶

Chromium's long-standing gap was that only the current site could offer installation, and only via the beforeinstallprompt event. Microsoft proposed the Web Install API: navigator.install(), which asks the browser to install the current site or another site identified by its manifest URL.

const button = document.querySelector("#install");

button?.addEventListener("click", async () => {
  if (!("install" in navigator)) return; // Chromium experiment only; see below.
  try {
    // No arguments: install the current document's app. Requires a manifest "id".
    await navigator.install();
    // Another app: navigator.install({ manifest: "https://suite.example/mail/manifest.json" })
  } catch (error) {
    if (error.name === "AbortError") return; // The user declined.
    // DataError: manifest could not be fetched, parsed or its id did not match.
    // NotAllowedError: no transient user activation (call only from a click).
    // InvalidStateError: called outside the top-level frame or from a sandboxed context.
    console.warn("Install failed:", error.name, error.message);
  }
});

The timeline:

• November 24, 2025: Microsoft announced an origin trial for navigator.install() in Edge 143–148 on desktop; chromestatus records the Chromium origin trial as running from 143 to 148 and extended through 150.
• 2026: a second origin trial covered a declarative <install> element (Chrome 148–153 on desktop): a browser-rendered, trusted install button that works without JavaScript. The origin-trial design used installurl (a page that links the target app's manifest) and manifestid attributes; its successor design uses manifest and manifestId attributes. That trial has ended.
• September 2026: an Intent to Ship on blink-dev proposed shipping navigator.install() in Chrome 156 on desktop, with Android not supported; chromestatus lists the <install> element under the same intent. chromestatus lists WebKit's position as oppose (site-initiated installation is "a user decision whose flow should begin in browser UI") and Gecko as having no signal.

The debate mirrors the one Russell's 2015 essay anticipated: should an app earn installation through use, surfaced by the browser, or may a site ask for it directly? Chromium and WebKit have now given opposite answers.

2025–2028: Chrome Apps end of life and Isolated Web Apps¶

On ChromeOS, Chrome Apps are in their final phase-out. Google's Chrome Apps documentation states that Chrome Apps in kiosk mode used by Enterprise and Education customers are no longer supported after April 2027, and that all remaining Chrome Apps in managed environments reach end of life in October 2028. The high-trust capabilities Chrome Apps offered (raw sockets, embedding other sites with full control) now live in Isolated Web Apps: signed, bundled, versioned web apps with a strict Content Security Policy, initially available on enterprise-managed ChromeOS devices through admin policy. They are covered on Isolated Web Apps.

Where the standards stand in September 2026¶

• Service Workers: W3C Candidate Recommendation Draft (latest September 17, 2026).
• Web Application Manifest: W3C Working Draft (latest August 13, 2026), editors from Apple, Google and Thinktecture.
• Push API and Notifications API: implemented in all three engines, with Safari restricting push on iOS and iPadOS to Home Screen web apps. The Badging API is implemented in Chromium and Safari (installed web apps only), not in Firefox.
• Declarative Web Push: shipped in Safari; proposed changes to the Push API and Notifications specifications are under discussion with other vendors.
• Web Install API and <install>: WICG incubation, Chromium Intent to Ship pending, WebKit opposed.

Year-by-year summary¶

What the history teaches¶

Four lessons from this history show up again and again in the rest of this site.

1. Programmable primitives beat declarative magic, until the patterns are known. AppCache failed because it hard-coded one strategy. Service workers succeeded because they hard-code nothing. Once a decade of real usage revealed the common patterns, declarative layers came back (Static Routing, Declarative Web Push) as optimizations with the programmable model as the fallback. When you design your own caching layer, follow the same order: explicit code first, abstraction later. See Caching Strategies.

2. The URL is the product. Every approach that removed the URL (Chrome packaged apps, Firefox OS packaged apps, Windows packages) died. PWAs kept the URL and let installation be an enhancement. Linkability, indexability and zero-install sharing are not nice-to-haves; they are why the model survived. See SEO for PWAs.

3. Installability criteria converge toward "less". Chrome's 2015 banner required HTTPS, a manifest, a service worker and engagement. By 2026 Chrome drops the service worker requirement and lets users install any page, Safari has zero requirements, and Firefox on Windows pins any site. The manifest and service worker have shifted from gatekeepers to quality signals. See Installability Criteria.

4. Platform politics are part of the engineering. The 2024 DMA episode, the WebKit opposition to the Web Install API, Chromium-only Fugu APIs and store policies all affect what you can ship. Build with progressive enhancement, feature-detect everything, and keep the baseline experience independent of any single vendor's decisions. See PWA vs Native vs Hybrid and When to Build a PWA.

Further reading¶

On this site

• What Is a PWA?: the definition and the ten characteristics explained
• Core Building Blocks: how the primitives described here fit together
• Installability Criteria: the current rules, per browser
• Service Worker Lifecycle: the design that replaced AppCache
• Static Routing API: the declarative router, finally shipped
• Web Push on iOS & Safari: iOS 16.4 push and Declarative Web Push
• iOS & iPadOS: current Apple platform behavior, including the EU
• Trusted Web Activity: PWAs in Google Play

External references

• Progressive Web Apps: Escaping Tabs Without Losing Our Soul, Alex Russell (June 15, 2015)
• Application Cache is a Douchebag, Jake Archibald (A List Apart, 2012)
• Service Worker: first draft published, Jake Archibald (2014)
• Service Workers publication history (W3C)
• PWAs: Past, Present, Future (ChromeOS.dev)
• Preparing for AppCache removal (web.dev)
• Welcoming Progressive Web Apps to Microsoft Edge and Windows 10 (Microsoft Edge blog, 2018)
• Workers at Your Service (WebKit blog, February 2018)
• Web Push for Web Apps on iOS and iPadOS (WebKit blog, 2023)
• Meet Declarative Web Push (WebKit blog, 2025)
• News from WWDC25: WebKit in Safari 26 beta (WebKit blog)
• Lighthouse v12.0.0 release notes
• The Web Install API is ready for testing (Microsoft Edge blog, 2025)
• Unlocking new capabilities for the web: Project Fugu (Chrome for Developers)