Installing a website sounds like a category error until you’ve done it. You land on a page, a small icon appears in the address bar, you click it, and there’s now an app on your desktop that opens in its own window with no tabs and no URL bar. Same site underneath. Different container.
That’s a progressive web app. Chrome, Edge, and Safari all handle installation now, although what each browser checks before it offers, and what you actually get afterward, varies by platform.
One thing worth clearing up early, because it confuses anyone poking at audit tools: Google removed the dedicated PWA scoring category from Lighthouse in version 12, released in May 2024, after simplifying Chrome’s installability requirements (Google, Chrome for Developers, 2024). The performance and best-practices audits still apply. There’s just no separate installability score sitting next to them anymore.
What Is a Progressive Web App?
Take an ordinary website built with the same HTML, CSS, and JavaScript as everything else. Add a manifest file and a background script. The browser will now let someone install it and run it like native software.
That’s the whole idea. Everything past this point is detail.
The category is a web application, not native software. What separates it from any other site is what happens once a browser decides the thing qualifies for installation:
- Sits on a home screen with its own icon
- Opens in a standalone window, no browser address bar
- Keeps working without a live network connection
- Sends push notifications like a downloaded app
None of that requires new code underneath. The same markup and scripts that render inside a browser tab render the installed version too.
People confuse this with hybrid apps constantly, and the two aren’t the same. Hybrid apps wrap web code inside a native shell, the way Capacitor does, then go through app store submission and review anyway. A progressive web app skips that packaging step for most install paths.
The term has a specific origin. Designer Frances Berriman and Google engineer Alex Russell coined “progressive web apps” in 2015 for sites that used service workers and web app manifests to behave like first-class installed software.
X (formerly Twitter) runs one today. So do Starbucks and Alibaba, though each of them arrived at it while trying to fix a completely different problem.
How Does a Progressive Web App Work?
A service worker handles the offline behavior. A web app manifest tells the browser how the installed version should look and launch. And none of it runs at all without HTTPS, which browsers treat as non-negotiable rather than advisory.
Service Worker and Offline Caching
The script sits outside the page, on its own thread, with a lifecycle the browser manages independently of whether any tab is open. That’s the part that trips people up the first time. Written in JavaScript, it intercepts network requests through the fetch event and decides, request by request, whether to answer from cache or go to the network.
Offline mode falls out of that. Which files get stored depends on the caching strategy you pick: cache-first for the app shell, network-first for data that changes often, stale-while-revalidate when you want a bit of both.
- Cache API stores static assets like scripts, styles, and icons
- IndexedDB stores structured data such as saved articles or draft form entries
- Background sync queues actions made offline until a connection returns
Pinterest uses the Workbox library for this layer, caching JavaScript and CSS bundles with a cache-first strategy so the interface shell loads instantly on repeat visits.
Web App Manifest and Display Settings
Everything about how the installed app presents itself lives in one JSON file, usually named manifest.json. The fields inside cover the presentation details a browser has no way to guess on its own.
- Name and short name shown under the icon
- Icon set for different screen densities
- Theme color and background color for the splash screen
- Display mode: standalone, fullscreen, or minimal-ui
- Start URL, the page that opens on launch
The HTML markup that renders once the app opens is no different from what a browser tab would show, styled the normal way.
Browsers refuse to register a service worker on an insecure origin, so HTTPS isn’t a recommendation here. Without it, nothing above happens.
How Do Users Install a Progressive Web App?
Installation starts with a browser prompt, not an app store search.
Once a site meets the manifest and service worker requirements, Chrome, Edge, and other Chromium browsers show an install icon in the address bar or a banner inviting the user to add the app.
Browser Install Prompts
Before offering to install anything, a browser scans for a valid manifest, a registered service worker, and an HTTPS connection. Miss any one of those and no prompt appears, no matter how good the site looks.
- Chrome and Edge show an install icon directly in the address bar
- Firefox on Android supports add to home screen through the browser menu
- Safari on iOS requires a manual share-menu action instead of an automatic prompt
Because each browser applies its own criteria and its own prompt style, cross-browser compatibility becomes something to test deliberately rather than assume.
Android: WebAPK and Trusted Web Activity
Android goes further than a home screen shortcut. Chrome packages an installed progressive web app into a WebAPK, a small Android package generated on Google’s servers, so the app shows up in the app drawer and app switcher exactly like a native install.
There’s a second path if you want store distribution. Trusted Web Activity wraps the same web content in a minimal native shell, the wrapped app can be submitted to the Google Play Store, and users install it from the store while the content still runs as a web app underneath.
Twitter Lite shipped through exactly this route, appearing in the Play Store as a lightweight wrapper around the same progressive web app that ran directly in Chrome.
What Are Examples of Progressive Web Apps?
Twitter, Pinterest, Trivago, and Alibaba all rebuilt their mobile experience as a progressive web app, and each one published real numbers afterward. It held for a social network and for a hotel search engine alike, which suggests the approach isn’t tied to any one kind of product.
Each company went in to fix a specific problem with its mobile user experience, usually slow loads or heavy downloads on unreliable connections.
- Twitter Lite weighs 600KB compared to 23.5MB for the native Android app, and saw a 75% increase in Tweets sent after launch (web.dev, Google case study)
- Pinterest grew weekly active users on mobile web by 103% year over year following its PWA rewrite (Pinterest Engineering, 2018)
- Trivago reported engagement up 150% among users who added the PWA to their home screen, with a 97% increase in clickouts to hotel offers (Think with Google case study)
Alibaba’s PWA became one of its main channels for reaching first-time shoppers in markets where phone storage was scarce.
Progressive Web App vs Native App vs Website: What Is the Difference?
It borrows installability from native software while keeping the delivery model of a plain website, which puts it somewhere in between the two. Easier to see side by side.
| Attribute | Progressive Web App | Native App | Website |
|---|---|---|---|
| Installation | Browser prompt, no store required | App store download | Not installable |
| Offline access | Yes, via service worker cache | Yes, built in | No |
| Updates | Instant, no review process | Store review required | Instant |
| Distribution cost | Low, no store fee | Store commission applies | Low |
Of everything in that table, instant updates are the line that matters most day to day. A progressive web app changes the moment new code ships. No review queue, no waiting on a reviewer in another timezone to approve a one-character bug fix.
A website leans on responsive design to adapt across screen sizes and stops there, with no install path and nothing left running once the tab closes. Native apps sit at the other end, getting full device access and guaranteed store placement in exchange for a review cycle every time anything changes.
Most of these get built mobile-first, since the install and home-screen behavior is aimed at phones, and the same code still runs fine on a desktop browser.
Starbucks runs its ordering PWA alongside a native app rather than replacing it, so customers order from whichever one they happen to have open.
What Are the Benefits and Limitations of a Progressive Web App?
You trade some native capability for reach, speed, and lower distribution cost. Which side of that trade matters more depends entirely on the product.
Performance gains come mostly from the app shell model. The interface frame loads once from cache and only the content underneath changes between visits.
Lighthouse, Google’s auditing tool, scores this directly. A score above 90 in the performance category is the usual bar for a production-ready build. Lighthouse dropped its separate progressive web app category in 2024, so installability now gets judged through the manifest and service worker checks instead of a standalone score.
Uber built its ride-hailing PWA specifically for 2G networks and older Android phones, markets where the native app was simply too heavy to download.
Push notifications work through the Push API and Notifications API together, letting a progressive web app send updates the same way a native app does once the user opts in.
The arguments in favor stack up fast:
- No app store approval delay for updates or launches
- One codebase instead of separate iOS and Android builds
- Smaller download size, useful on slow connections and cheap devices
- Indexable by search engines, unlike most native app content
The honest downsides are narrower but real:
- Feature support varies by browser, especially on iOS
- No guaranteed listing in the App Store or Google Play Store unless separately packaged
- Background processing is more restricted than what native apps get
Device access is the biggest gap. A progressive web app can’t reach every hardware API a native app can, so Bluetooth peripherals, deep camera controls, and background location tracking still favor native code.
Which Browsers and Platforms Support Progressive Web Apps?
Support depends on the browser engine, not the browser name, and that distinction changes what actually works for a given user.
Chrome, Edge, and other Chromium-based browsers support the full feature set: install prompts, push notifications, background sync, and WebAPK packaging on Android.
iOS and Safari Limitations
Safari on iOS runs on WebKit, and WebKit has historically shipped progressive web app features later and with more restrictions than Chromium. The gaps that still bite:
- Install happens manually through the Safari share menu, not an automatic browser prompt
- Push notifications require the app to already be on the home screen before requesting permission
- Storage limits and background sync behavior remain tighter than on Chromium browsers
Apple closed one of the longest-standing of these in March 2023, when iOS and iPadOS 16.4 added Web Push support for home screen web apps (WebKit blog, Apple).
Rendering differs slightly between engines too, so even something as basic as how the viewport scales can look different on Safari than on Chrome or Edge.
If your audience is mostly iPhone, test on real Safari. Chromium behavior does not carry over.
How Do You Build a Progressive Web App?
Write the manifest, register the service worker, deploy over HTTPS, then test the install prompt. Nothing technically breaks if you shuffle that order, but testing install behavior before HTTPS is live just burns a debugging session on a problem you already created.
- Write the manifest. Define name, icons, start\_url, and display mode in manifest.json.
- Register the service worker. Point it at the files that need offline caching.
- Deploy over HTTPS. Without it, the service worker registration call fails silently in most browsers.
- Test the install prompt. Chrome DevTools’ Application panel shows exactly why a page does or doesn’t qualify.
Chrome loosened its side of this in 2024. A Chrome for Developers post described experiments removing some manifest field requirements from the installability check, aimed at simplifying what qualifies a page for the install prompt.
Choosing a Framework
Some frameworks ship an official path for this, others hand it off to plugins, and one major option no longer has anything at all.
| Framework | PWA Support |
|---|---|
| Angular | Official schematic generates the manifest and service worker |
| Vue | Plugin-based, through the Vite PWA plugin |
| React | No official solution since the Create React App PWA template was retired |
| Ionic | Native-feeling UI components layered on top of any of the above |
React’s own team deprecated Create React App for new projects on February 14, 2025, which retired its built-in PWA template along with it (react.dev).
Angular’s frontend tooling handles this best out of the box, and it isn’t close. Running “ng add @angular/pwa” installs the service worker package, writes the manifest, and drops in icon files automatically.
Alibaba went its own way and built Rax, a React-compatible framework, specifically to ship a progressive web app, server-rendered pages, and mini-app builds from one codebase.
None of this replaces normal backend work. The HTTPS certificate and hosting still need configuring at the server level before any frontend piece matters.
Auditing with Lighthouse and Workbox
Lighthouse used to score a dedicated Progressive Web App category out of 100.
Google removed that category in Lighthouse 12, which shipped to Chrome DevTools and PageSpeed Insights on May 10, 2024, after the underlying installability checks changed (Google Developers, PageSpeed Insights release notes).
Performance and best-practices scores still apply, and they still matter for how fast the app shell loads. There’s just no PWA pass or fail number left to chase.
Workbox is unaffected by any of that and still does the heavy lifting:
- Pre-built caching strategies (cache-first, network-first, stale-while-revalidate) as importable recipes
- Build plugins for webpack, Rollup, and its own CLI
- Precaching, so a list of build assets gets cached automatically on install
It remains a Chrome team project, and it’s still the fastest way to write a correct caching strategy without hand-rolling fetch event listeners yourself.
When Does a Progressive Web App Not Make Sense?
The wrong choice, clearly, when the product depends on hardware or platform behavior the web still can’t reach. A few situations come up over and over.
Deep hardware access is the obvious one. Bluetooth peripherals, precise background GPS tracking, and advanced camera controls (manual focus, RAW capture, depth sensors) still require native code. Photo and video apps with heavy in-app camera pipelines, the kind Instagram or Snapchat run, keep that capture step native even when the rest of the product lives on the web. Games built around frame-perfect animation or haptic feedback land in the same bucket, since that level of user interface responsiveness runs more reliably outside the browser.
Then there’s offline sync on iOS. The Background Sync API, the piece that queues actions made offline and sends them once a connection returns, is not implemented in Safari at all, desktop or mobile. That’s a firmer limit than general browser variation suggests. Firefox has taken the same position, and both vendors have flagged it as unlikely to change, so anything leaning on background sync for its core offline story needs a fallback plan on those two browsers (MDN browser compatibility data).
Discovery is the third problem, and it’s a business one rather than a technical one. Some products depend on being found inside the App Store or Google Play Store, not through a browser or a search engine. A subscription box service or a game competing for featured placement loses that entire channel without a native listing, because a progressive web app has no guaranteed shelf space there.
And if there’s no real offline use case, the whole exercise is overhead. A tool that only works against a live backend, a real-time trading dashboard for example, gets none of the benefit that makes the setup cost worth paying.
| Situation | Why a PWA Falls Short |
|---|---|
| Bluetooth or advanced camera features | Hardware APIs aren’t exposed to the browser |
| Background sync on iOS | Safari does not implement the Background Sync API |
| App store as the discovery channel | No guaranteed listing without native packaging |
| Offline use isn’t part of the product | The main technical advantage goes unused |
FAQ on What Is A Progressive Web App
What does PWA stand for?
PWA stands for progressive web app. Progressive refers to progressive enhancement, a page that works everywhere first, then adds installability and offline behavior where the browser supports it. Web app separates it from a native binary submitted to a store.
Why does a PWA require HTTPS?
Because a service worker can intercept and rewrite every network request a page makes, browsers restrict that power to secure origins only. Without HTTPS, registration fails silently, which protects users from a malicious script hijacking traffic on an unencrypted connection.
How do push notifications work in a PWA?
The user grants permission and the browser creates a subscription through the Push API. When the server sends a message to that subscription, the service worker wakes and displays it through the Notifications API, even with the site closed.
How much does it cost to build a progressive web app?
There is no separate price tag for being a PWA. Cost mirrors an ordinary responsive website, since the same codebase runs both, and scales with feature scope. Push infrastructure and offline sync add real engineering time beyond a basic manifest.
What are common mistakes when building a PWA?
Shipping without an offline fallback page is the most frequent one, so a lost connection just shows a browser error. Others include incomplete manifest icons, assuming Safari matches Chrome’s install behavior, and a service worker that caches stale content forever.
Can a progressive web app replace a native app entirely?
Not entirely. It replaces a native app for most content, commerce, and utility use cases, but hardware-dependent products, Bluetooth accessories, advanced camera pipelines, apps that live on app store discovery, still need native code alongside or instead of it.
What Happens to a Progressive Web App After It Launches?
Launch day is not the end of it. Cache versions, manifest updates, and service worker activation cycles all need ongoing attention from someone on the team, which makes this an active maintenance phase rather than a single deployment step.
Storage isn’t unlimited either. Browsers cap how much a service worker can hold in the Cache API and IndexedDB, so anyone leaning hard on offline content eventually has to evict older entries to stay under the ceiling.
After launch, keep an eye on cache versioning so stale assets get replaced automatically, on install and uninstall telemetry across platforms, and on periodic accessibility and performance re-audits.
That last one carries the most weight over time. Sustained web accessibility comes from catching interface regressions as they appear, not from one clean audit at launch.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- What is Backend in Web Development? - September 13, 2026
- What is Frontend Development? - September 11, 2026
- How to Make a Button in Figma: Design Best Practices - September 10, 2026
