What a progressive web app is

A progressive web app is a website that installs to the home screen, works offline, and can send push notifications from one web codebase, with no app store in the middle. Here is how it works and when it fits.

On this page

A progressive web app (PWA) is a website built to behave like an installed app. It installs to the home screen, works offline, and can send push notifications, all from one web codebase, with no app store in the middle. If you have ever wondered what a PWA is, that is the whole idea: the web page and the app are the same thing. It is one of the routes covered in mobile app development.

How a progressive web app works

Open a PWA and, on the surface, it is just a site loading in a browser. The difference is what runs underneath. A modern browser reads a small set of extra files and, when they are present, treats the site as installable software rather than a page you visit and forget.

Three things make that happen. A service worker sits between the app and the network, caching the interface and data so the app keeps working when the connection drops and syncs back up when it returns. A web app manifest tells the browser how to install the app, which icon to use, and how it should launch. The Push API delivers notifications on platforms that allow it.

Because it is still the web, there is no build to submit and no review queue. You deploy a fix and every user has it on their next launch. That single trait, no app-store gate between a change and your users, is the reason a lot of teams reach for a PWA in the first place.

The core technologies, in a bit more depth

The service worker does the heavy lifting. It is a script the browser runs in the background, separate from the page, so it can intercept network requests, serve cached responses, and keep an app usable on a train or a plane. Caching strategy is where the real work goes: what to serve from cache, what to fetch fresh, and what to queue for later.

The manifest is a short JSON file, and it is easy to underrate. It carries the app name, icons, theme color, and the display mode. Set display to standalone and an installed PWA drops the browser chrome and opens like a real app. Miss the manifest and the browser treats your site as a bookmark. Worth getting right early.

Web push is the piece that took longest to arrive everywhere. It uses standard VAPID keys on your server, so you do not need an Apple developer certificate just to notify a web user. Background Sync, which lets a service worker finish queued work once the network comes back, is handy but still mostly a Chromium feature, so treat it as a nice-to-have and design for it being absent.

PWA vs native vs cross-platform

The honest comparison is about trade-offs, not a winner. Here is the short version of how a PWA stacks up against the two common alternatives.

  • PWA — one web codebase, instant updates, no store required, best reach per dollar. Gives up the deepest device APIs and the storefront itself.
  • Native (Swift or Kotlin) — the full device, the best performance ceiling, a real App Store or Play listing. Costs you two codebases and a review cycle on every release.
  • Cross-platform (React Native, Flutter) — one codebase that compiles to real native apps, so you keep the store listing and most device access. You take on a framework layer and its quirks.

A useful rule of thumb: if the store listing, app-store discovery, or a hardware-heavy feature is the point, go native or cross-platform. If reach, speed of iteration, and turning an existing site into an app are the point, a PWA usually wins. The full weighing lives in the native versus cross-platform decision.

When a PWA is the right call

Reach for a PWA when your product already lives on the web and you want it on more screens without splitting into store builds. Content sites, e-commerce, booking flows, dashboards, and internal tools all fit the mold. Anything where fast loads on a shaky connection matter more than squeezing the last frame out of the GPU is a good candidate.

It is also the pragmatic choice when budget or timeline is tight. One codebase, one deploy pipeline, one bug to fix in one place. Startups use this to get an installable, offline-capable app in front of users without funding a separate iOS and Android team.

Where it starts to strain: heavy 3D or AR, tight Bluetooth or NFC integration, background location, or anything that leans on the newest platform SDKs. If your roadmap depends on features like those, a PWA will fight you, and native is the cleaner path.

Platform support and the iOS reality

On Chrome, Edge, and Android generally, PWAs are a first-class citizen: installation, offline, push, and background features all work as documented. Service workers themselves are supported across every evergreen browser, so the offline foundation is solid everywhere.

iOS is where expectations need a reality check. Apple shipped web push for home-screen web apps in iOS and iPadOS 16.4, which closed the biggest historical gap. Push now works, but only after the user adds the app to the home screen and launches it from there. A plain Safari tab still cannot receive web push, and some device APIs remain unavailable. In early 2024 Apple briefly signaled it might drop home-screen web apps in the EU during its Digital Markets Act changes, which alarmed the web community. It walked that back, and installable web apps stayed.

The practical takeaway: build the PWA, but test it on a real iPhone and set expectations with stakeholders. What ships on Android is not always what an iPhone user gets.

PWAs in the wild

The pattern has a long track record, and a few examples still come up constantly. Starbucks built its ordering experience as a PWA whose initial bundle came in around 233 KB, roughly 99.84% smaller than its 148 MB iOS app, per the case study from the agency that built it. Uber shipped a core PWA bundle of about 50 KB gzipped, small enough to load in under three seconds on a 2G connection, so a ride is bookable on almost any device.

Twitter Lite, Pinterest, and Tinder all shipped PWAs to reach users on slow networks and low-end phones, and each reported gains in engagement and data use after the switch. Exact figures vary by retelling, so treat the headline percentages with a pinch of salt. The direction is consistent: a smaller, faster, installable web app that meets people where their connection actually is.

When the store is not the point and the web is where you already are, shipping one is progressive web app development.

Frequently asked questions

  • Yes, with caveats. Since iOS and iPadOS 16.4 you can add a progressive web app to the home screen, run it in standalone mode, and receive web push notifications. The catch is that push only fires once the app is installed to the home screen, not from a normal Safari tab, and a few deep device APIs stay off-limits.

  • Not as a raw URL. Neither store accepts a manifest and service worker on their own. On Android you wrap the PWA in a Trusted Web Activity (tools like Bubblewrap or PWABuilder generate the package) and ship a normal AAB to Google Play. On iOS you wrap it in a native WebView shell and submit that. The store sees an app, and your users still get the PWA.

  • Neither wins outright. A PWA gives you one codebase, instant updates, and no store gatekeeper, which is ideal for reach and content-heavy products. Native still owns the deepest device features, the smoothest performance ceiling, and the storefront itself. Pick based on which of those you actually need.

  • PWA stands for progressive web app. The 'progressive' part points to progressive enhancement, where the site works as a plain web page everywhere, then layers on installability, offline support, and push wherever the browser can handle them. The same URL degrades gracefully on older browsers and lights up fully on modern ones.

  • Mostly platform politics and habit. Apple kept web push and installation limited on iOS for years, so teams that needed those features defaulted to native. App stores are still where most users expect to find apps, and marketing budgets follow. The technology is ready, but distribution and expectations lag behind it.

Related expertise