A progressive web app is a website that can install on a device and open in its own window like a platform-specific app. It’s built with ordinary web technologies and runs from one codebase in the browser, so anyone with a URL can get to it. No app store listing needed.
Plenty of guides still say you need a service worker before a PWA can install. That stopped being true for menu installs in Chrome version 108 on mobile and 112 on desktop (Chrome for Developers, 2023), and MDN treats the service worker as optional.
What Are Progressive Web Apps?
Technically, a PWA is still a website. It runs inside a browser engine, even after it has been installed and sits on a home screen next to everything else (MDN Web Docs, December 2025).
Plain web apps already reach every browser from one URL. A PWA keeps that reach and adds an install flow, offline operation, and push messages. Those ordinary web apps are the starting point, and the PWA features sit on top of them.
Google’s web.dev has organized PWA design around capable, reliable, and installable since January 2020. Capable means modern web APIs reach features that used to belong to platform apps. Reliable is about loading quickly on slow, flaky, or missing networks. Installable means the app opens in its own window from the home screen, dock, or taskbar.
MDN adds progressive enhancement as a fourth trait, meaning the app still works as a normal site in browsers that lack the newer APIs.
Unlike native apps, which the operating system runs directly, a PWA depends on a browser engine.
It needs no app store, although it can ship through several. And it does not have to be a single-page app, since the two ideas are independent.
Alex Russell and Frances Berriman named the pattern in 2015, according to Russell’s own site.
How Do Progressive Web Apps Work?
HTTPS sits underneath everything. On top of it, the browser reads a web app manifest to install the app, and a service worker runs in the background to handle requests and push events.
| Component | Format | Job |
|---|---|---|
| HTTPS | Protocol (localhost allowed in development) | Secure context for install and service workers |
| Web app manifest | JSON file linked from every page | Name, icons, start URL, display mode |
| Service worker | JavaScript file in its own thread | Intercepts requests, caches, handles push |
A service worker’s life starts with the install event, when the worker downloads and can precache the interface files. Activate comes next, and that’s where old cache versions get cleaned up. After that it spends its time in the fetch event, intercepting each request and deciding what to send back.
MDN splits a PWA into two parts. The main app handles the user interface, and the service worker handles offline and background tasks. Precaching the interface skeleton (the app shell pattern) lets the UI render at launch without touching the network.
Installing the service worker is a different event from installing the PWA, and people mix them up constantly. The worker installs on the first page visit, even if the visitor never installs the app (MDN, 2025).
What Makes a Progressive Web App Installable?
Serve the app over HTTPS and link a manifest with a name, icons, a start URL, and a display mode, and the browser will promote it for installation. Chrome adds an engagement check on top of that: one click or tap and at least 30 seconds on the page (web.dev, updated September 2024).
Per web.dev, Chrome wants these manifest members:
- name or short_name
- icons, including a 192px and a 512px icon
- start_url
- display set to fullscreen, standalone, minimal-ui, or window-controls-overlay
- prefer_related_applications absent or false
Older guides still list a service worker with a fetch handler as mandatory. Chrome dropped that requirement for menu installs in version 108 on mobile and 112 on desktop, but the automatic install prompt still looks for a fetch handler (Chrome for Developers, December 2023).
MDN treats the service worker as optional for installability. Chrome also ignores empty fetch handlers, so adding a no-op handler just to trigger the prompt gains you nothing. I’d skip that trick entirely.
Installing from the browser
Install support differs by platform (MDN, as of October 2026).
On desktop, Chromium browsers install manifest-based PWAs and Safari 17 adds any site to the Dock. Firefox does not install from a manifest.
Android is narrower. Only Chrome with Google Mobile Services and Samsung Internet install PWAs as WebAPKs, while other browsers add a shortcut.
Since 16.4, iOS installs from the Share menu in Safari, Chrome, Edge, Firefox, and Orion.
A site can show its own install button through the beforeinstallprompt event. iOS does not support that event (MDN).
To check a site in Chrome:
- Open the site, open DevTools, and select the Application panel.
- Open the Manifest pane. Errors such as an icon that fails to load appear in the Installability section.
- Open the Service Workers pane to confirm registration, and tick Offline to test the offline path.
- Click the Install icon in the address bar with the Console open, since manifest issues are logged there.
Lighthouse 12 (Chrome 126 DevTools) removed its PWA category, so installability debugging now lives in DevTools.
Publishing through app stores
Content in a Trusted Web Activity must pass the installability criteria and reach a Lighthouse performance score of 80 at the start URL, per the quality criteria Chrome published for Chrome 86 in 2020.
PWABuilder packages a PWA for Google Play, the Microsoft Store, the Apple App Store, and the Meta Quest Store. It needs a public URL, a complete manifest, and HTTPS (web.dev, March 2023).
Google Play charges a one-time $25 developer fee and Apple charges $99 a year. Microsoft Store registration is free for individual developers (company accounts pay a one-time $99 fee), and Meta Quest is free. Store rules can require the store’s own payment system and a commission on purchases.
A Trusted Web Activity crashes the Android app instead of falling back when digital asset link verification fails at launch. The same happens if an offline resource request does not return HTTP 200, or if the app serves an HTTP 404 or 5xx error (Chrome for Developers).
How Do Progressive Web Apps Work Offline?
Every network request passes through the service worker, which answers from the Cache API, from the network, or from both, depending on the caching strategy. Most PWAs pick a different strategy for each resource type.
The Cache API stores Request and Response pairs. Structured app data, such as a draft message or a task list, belongs in IndexedDB instead.
| Strategy | How it works | Fits | Fails when |
|---|---|---|---|
| Cache first | Serves the cached copy, goes to the network on a miss | App shell, fonts, versioned files | The copy stays old until a new service worker installs |
| Network first | Tries the network, falls back to the cache | Message lists, fresh data | The offline copy is only as new as the last good request |
| Stale while revalidate | Serves the cache, refreshes it in the background | Images, avatars, minor data | Workbox revalidates on every request, even for fresh copies |
Precaching happens in the install event, and runtime caching happens in the fetch handler. Workbox wires this up with workbox-routing and workbox-strategies, for example stale while revalidate for images and cache first for CSS and JavaScript (Chrome for Developers).
Cache first causes the classic stale-asset problem after a deploy. Version the cache name and delete old caches in the activate event (MDN, June 2025).
Eviction of cached data is rare, according to MDN. The quota math still surprises people, though. Chrome counts each cached opaque response, a cross-origin response without CORS, as approximately 7 MB at minimum (Workbox documentation, Chrome for Developers).
Which App-Like Features Do Progressive Web Apps Support?
An installed PWA can send push notifications, sync data in the background, and open in a standalone window. Badges, share targets, and file handling tie it into the operating system as well. Support differs by browser for each of them.
Push notifications
The Push API, the Notifications API, and a service worker work together, and the browser starts the service worker when a push message arrives (MDN, 2025).
On iOS, Web Push works for Home Screen web apps since iOS 16.4. The permission request must follow a direct user action, such as tapping a subscribe button, per the WebKit blog (February 2023).
Background sync
The Background Synchronization API defers a request until the connection returns, so a message composed offline sends later.
Chrome 49 and Edge 79 support it, Firefox holds a negative vendor position, and Safari does not implement it (web-features data). MDN marks the API as limited availability.
Feature-detect it, and when it is missing, tell the user the send failed and let them retry. Treat Background Sync as an enhancement, never as the only route for saving user data.
Standalone windows and badges
Setting display to standalone removes the browser interface, and iOS 16.4 added the Badging API for Home Screen web apps.
Device access
PWAs can register as share targets and reach some device features. web.dev acknowledged in 2020 that other capabilities remain out of the web’s reach.
Progressive Web Apps vs Native Apps vs Responsive Websites
A PWA ships like a website and installs like an app, which puts it between the other two. What it gives up is full device access and automatic store visibility.
| Dimension | PWA | Native app | Responsive website |
|---|---|---|---|
| Distribution | Web link, install prompt, optional store listing | App store download | Web link only |
| Offline use | Service worker caching | Full | None by default |
| Device access | Web APIs, some gated by browser | Full, through the OS SDK | Web APIs in a tab |
| Updates | Deploy to the server | Store release and review | Deploy to the server |
| Codebase | One web codebase | One per platform | One web codebase |
An installed PWA usually takes less than 1 MB of device storage, according to web.dev (2020). Limited storage is one of the top reasons people uninstall apps.
React Native and Flutter reach both stores from one codebase, a form of cross-platform app development that keeps full device access. The price is store accounts and review.
Ionic with Capacitor wraps a web app in a native shell. That produces hybrid apps that reach stores while the interface stays web code.
Content, commerce, and account tools lean PWA, while hardware-heavy products lean native.
Which Browsers and Operating Systems Support Progressive Web Apps?
Support follows the browser engine, not the browser name. On iOS, every browser runs WebKit unless Apple has granted an entitlement for another engine.
Apple’s App Review Guidelines (updated October 2026) require apps that browse the web to use WebKit, with an alternative-engine entitlement for the EU and Japan. Outside those regions, Chrome or Edge on an iPhone shares Safari’s PWA limits.
Apple has shifted the picture several times since 2024, and the table below sorts out which release did what.
| Release | Change | Effect on PWAs |
|---|---|---|
| iOS 17.4 (March 2024) | Home Screen web apps stay available in the EU | Same WebKit-based behavior as elsewhere |
| iOS 18.4 (2025) | Declarative Web Push for Home Screen web apps | Push works without a service worker |
| iOS 26 (2025) | Every site added to the Home Screen opens as a web app by default | A manifest is no longer needed for standalone display |
The WebKit blog documents the last two rows (2025). Apple’s developer support statement covers the first.
Sources disagree on the EU. Some 2024 write-ups still say iOS dropped Home Screen web apps there, but Apple removed them only in the second iOS 17.4 beta and reversed course before release, per Engadget (March 2024).
Test each feature on a physical iPhone, because the iOS version decides which row of that table applies.
Which Companies Run Progressive Web Apps?
Twitter, Nikkei, and Starbucks have each published PWA results. The figures come from the companies or their agencies, not from independent measurement.
After its PWA launch, Twitter reported 65% more pages per session (web.dev, 2020) and an app size reduced by over 97% (web.dev, 2020). Nikkei saw 2.3 times more organic traffic after switching (web.dev, 2020). Starbucks built a 233 KB ordering and store locator PWA against the 148 MB original iOS app, as reported by NearForm, the agency that built it.
Twitter and Starbucks both cut payload size by more than 97%. Nikkei’s gain sits in organic traffic, a channel store-only apps do not get, since MDN lists search indexing among the benefits of web distribution.
Treat the percentages as best cases. None of these sources isolates the install prompt or push from the speed gains.
When a Progressive Web App Is the Wrong Choice
A PWA is the wrong fit when the product needs hardware the browser does not expose or depends on store discovery. It’s also a poor fit if it holds data users cannot afford to lose on Safari.
Hardware access
MDN marks the Web Bluetooth API as limited availability and experimental, so it is not Baseline. An app that pairs with devices cannot count on it across browsers.
Storage on Safari
Quota is rarely the problem. Since Safari 17 and iOS 17, an origin can use roughly 60% of total disk, and a Home Screen web app gets the same limit (MDN, January 2026). Older guides still quote an initial 1 GiB cap that no longer applies.
Eviction is the real risk. With cross-site tracking prevention on, Safari deletes script-created data for an origin after seven days of browser use without user interaction (MDN, January 2026). WebKit’s 2020 tracking-prevention post gives Home Screen web apps their own counter of days of use.
Store visibility
Apple’s guideline 4.2 says an app should include features, content, and UI that go beyond a repackaged website (App Review Guidelines, October 2026). A PWA wrapped for the App Store has to show native features to pass.
When one of these walls applies, the next comparison is between native, hybrid, and cross-platform apps.
Progressive Web Apps FAQ
Can search engines find a PWA?
Yes. A PWA is a website, so it is discoverable through web search like any other site (MDN, 2026).
An app store listing is optional and adds a second channel rather than replacing the first.
Is a PWA the same as a single-page app?
No. A single-page app is one HTML page where JavaScript fetches new content when users click links. A PWA is defined by its installability through a web app manifest.
Many PWAs are built as single-page apps, but neither requires the other (MDN, 2025).
How do I install a PWA on an iPhone?
Open the site in Safari, tap Share, then Add to Home Screen. On iOS 26 the Open as Web App switch is on by default, so the icon launches a standalone window.
Turn the switch off and the icon becomes a plain bookmark (WebKit blog, 2025).
Do PWAs work on desktop computers?
Yes. Chrome added desktop PWA install in 2019, four years after mobile install arrived (Chrome for Developers, 2023).
An installed PWA then appears in the Start menu on Windows and the Applications folder on macOS (web.dev, 2024).
How much does a PWA cost compared with a native app?
No single price applies, because cost follows scope. A PWA ships from one web codebase and needs no developer account for web distribution, while store packaging does (web.dev, 2023).
Budget developer time and hosting first, and store fees only if you package the app.
Which tools help build a PWA?
Workbox handles service worker caching. PWABuilder packages a PWA for stores, and Bubblewrap generates an Android project for a Trusted Web Activity from the manifest.
No framework is required, because a PWA uses standard web APIs.
Who invented the term progressive web app?
Alex Russell and Frances Berriman named the pattern in 2015. Russell’s essay that year used the shorter label Progressive Apps, after Berriman’s earlier variant, Progressive Open Web Apps (Bruce Lawson, 2015).
Where to Start Turning a Website into a PWA
Start with HTTPS. Service workers run only on secure origins, so nothing else works without it.
The manifest goes second, ahead of the service worker, because it delivers installability without the stale-asset risk of caching logic. The trade-off is that the app installs but still fails offline until the service worker ships.
Push notifications come last, since they normally depend on the service worker (Declarative Web Push on iOS 18.4 and later is the exception) and, on iOS, on an installed Home Screen web app.
This order holds as of October 21, 2026. If Safari ships Background Sync, which MDN lists as not implemented there, offline form submissions would move ahead of push.
- How to Run a React App in VS Code Step by Step - October 23, 2026
- Transactional or marketing email: which messages your app should send itself - October 23, 2026
- How Software Teams Write SOPs for Releases and Deployments - October 22, 2026
