Progressive Web App (PWA)

What Is a Progressive Web App (PWA)?

A progressive web app (PWA) closes the gap between a website and an app store listing, removing the necessity of releasing a second product. Open the site in a phone's browser, and once it meets a small set of installability criteria, it offers to install itself. An icon appears on the home screen and the browser chrome disappears, while the same code that rendered the page now runs full-screen and caches itself for the next time the connection fails. The source stays the same. What changes is which capabilities the browser is willing to hand the page once it asks for them over a secure connection.

Chrome engineer Alex Russell and designer Frances Berriman coined the term in 2015. They named a pattern for building experiences that work across devices from a single codebase instead of a native app per platform. The label stuck because it gathered together several browser capabilities that were already shipping piece by piece, installability and offline caching chief among them. Developers finally had one name they could reference in a single conversation.

Retailers and publishers adopted the pattern early because it let them ship a faster, installable experience without maintaining a separate iOS and Android codebase alongside the website. The trade-off showed up just as early: the deepest device integrations, and the widest reach into app store search, still belong to native apps built with each platform's own SDK.

Why Businesses Choose a Progressive Web App?

Maintaining a website alongside separate iOS and Android builds multiplies the places a bug can hide and the release calendars a team has to track. A progressive web app collapses that back to one codebase and one release process, so a fix ships the moment it's deployed instead of waiting on a store review queue that can run days for routine updates and longer for anything touching permissions or payments.

Apple and Google both review submissions and can reject an update for reasons unrelated to code quality. Both also take a cut of in-app purchases made through their billing systems. A PWA installs straight from the browser, which removes that review step and that revenue share for any business model that doesn't depend on the store's payment system.

On markets where device storage is scarce and connections drop often, a small installable web app reaches people a large native download can't. This is part of why PWAs concentrated early in e-commerce and publishing: the audience is broad and the app doesn't need deep hardware access, while every extra megabyte of install size costs conversions at the door.

How Does a Progressive Web App Work?

• A web app manifest tells the browser the app is installable. This is a JSON file linked from the page that names the app, points to its icons, sets the start URL, and declares a display mode such as fullscreen or standalone. The browser reads it to decide what to show when someone taps "Add to Home Screen," and what to open when they tap the resulting icon.

• A service worker gives the app a life outside the browser tab. It's a script that runs on a separate thread, sitting between the app and the network. It can intercept requests and serve cached responses when there's no connection. It also keeps running briefly after the tab closes, which is what makes background sync possible alongside offline loading.

• HTTPS is a precondition. Browsers refuse to register a service worker over a plain HTTP connection, since a script with that much control over network traffic would be a serious attack surface on an unencrypted page. This is one reason PWA adoption tracked the broader move to HTTPS-by-default across the web.

• An app shell loads once and stays. The static layout and navigation chrome get cached on the first visit, so return visits render instantly while only the content underneath fetches fresh. This is the mechanism behind the instant-load feel that native apps have and plain websites usually don't.

• Push and Notifications APIs handle re-engagement. A device that grants permission gets a subscription endpoint the backend can send messages to, even while the app isn't open. Android has supported this for years without conditions. iOS only added it in version 16.4, in 2023, and still requires the app to be installed to the home screen first before it will allow the permission prompt at all.

• Responsive layout is a starting requirement. Since there's no separate native UI per platform, one layout has to hold up from a small phone screen to a wide desktop window.

What Tools Do Teams Use to Build a Progressive Web App?

• Service worker and build tooling: Workbox, Google's library for generating and managing service workers, handles caching strategies so teams don't hand-write the low-level cache logic. The Vite PWA plugin does the same inside a Vite build pipeline.

• Frameworks with PWA support built in: Angular ships an official PWA schematic (ng add @angular/pwa) that wires up the manifest and service worker automatically. Next.js and Nuxt reach the same result through widely used community plugins, next-pwa and @vite-pwa/nuxt.

• Auditing and packaging tools: Lighthouse, built into Chrome DevTools, still audits manifest validity and installability even though it retired its dedicated PWA scoring category in 2024. PWA Builder, maintained by Microsoft, packages an existing PWA for direct submission to the Microsoft Store and, through a Trusted Web Activity wrapper, for the Google Play Store.

What Are the Key Characteristics of a Progressive Web App?

• Installable without an app store. The browser itself offers the install prompt once its criteria are met, skipping the submission and review step a native app requires.

• Offline-capable by design. Cached responses served by the service worker keep core screens usable through a dropped connection instead of returning a browser error page.

• Linkable and crawlable. Every screen keeps a normal URL that search engines can index and users can share, unlike a screen buried inside a native app with no equivalent web address.

• Responsive across viewport sizes. One layout serves a phone screen and a desktop browser window alike, since there's no separate native interface built per platform.

• Re-engageable through push. Notifications work without the app open, but the permission model and background limits differ enough between Android and iOS that the same feature behaves differently depending on the device.

• Instantly updatable. A deploy is the update. There's no store approval step standing between a fix and the person using it.

What Are the Benefits of a Progressive Web App?

• Cuts distribution friction. No store review queue and no per-platform submission process stand between finishing a build and putting it in front of users.

• Lowers maintenance cost. Engineering effort funds one codebase instead of duplicating the same feature across a website and separate native builds for each mobile platform.

• Extends organic reach. Indexable URLs bring in search traffic that a native app's store listing can't capture on its own, since the app has no public web address to rank.

• Keeps the install lightweight. A PWA loads incrementally instead of requiring a large upfront download, which matters on constrained storage or a slow connection.

• Keeps working through network drops. The cached app shell and assets keep core screens usable during a connectivity gap that would otherwise blank a plain website entirely.

What Are the Challenges and Trade-offs of a Progressive Web App?

• iOS support trails Android and gates features behind installation. Push notifications only work once someone has added the PWA to their home screen. Apple only enabled that behavior in iOS 16.4, years after Android had it unconditionally. Teams targeting iPhone users end up designing an install prompt into onboarding, an extra UX step a native app doesn't need.

• A PWA's footing on iOS is a policy decision. Apple announced it would remove home screen web apps entirely in the EU ahead of iOS 17.4 in February 2024, then reversed the decision within weeks under regulatory pressure. Nothing rules out a similar move later, while a native app's distribution risk runs through published store guidelines instead of one platform's ad hoc call.

• Deep hardware access belongs mostly to native code. Background location tracking and full Bluetooth peripheral access sit outside what browser APIs expose. A PWA that needs either ends up shipping a thin native wrapper for that one feature, which reintroduces the second codebase the pattern was meant to avoid.

• Skipping the app store also means skipping app store search. A large share of users still go looking for an app inside a store before anywhere else. This means that a PWA has to earn installs through its own marketing and onboarding.

What Is the Difference Between a Progressive Web App and a Native App?