Progressive Web Apps (PWAs): Capabilities, Limitations, and When to Use Them
Progressive Web Apps occupy a defined architectural position in the app development landscape — delivering installable, app-like experiences through standard web technologies without requiring distribution through Apple's App Store or Google Play. This page covers the technical definition of PWAs, how the underlying browser APIs function, the deployment scenarios where PWAs perform well, and the decision boundaries that separate PWA-appropriate projects from those requiring native or cross-platform builds.
Definition and scope
A Progressive Web App is a web application that meets a set of technical criteria — defined primarily by Google's web platform teams and codified in the web.dev PWA documentation — enabling it to behave like a native application across desktop and mobile environments. The three foundational requirements are: serving over HTTPS, registering a Service Worker, and including a Web App Manifest file that declares name, icons, and display mode.
PWAs fall into two broad classification tiers based on integration depth:
Baseline PWAs satisfy the minimum installability criteria. They load reliably on repeat visits via Service Worker caching, can be added to a device home screen, and operate across modern browsers. They do not access hardware APIs beyond what the standard browser context allows.
Capability-extended PWAs utilize Project Fugu APIs — a collaborative initiative between Google, Microsoft, and other Chromium contributors tracked at chromestatus.com — to access system-level capabilities including file system access, Bluetooth, NFC, clipboard, and badging. These APIs have variable browser support: as of the W3C's public API compatibility tracking, most Fugu APIs are fully supported in Chromium-based browsers (Chrome, Edge) but have partial or no implementation in Safari.
The Web App Manifest specification is maintained by the World Wide Web Consortium (W3C). The Service Worker API is specified under the W3C Service Workers standard, which defines the lifecycle, fetch interception model, and cache storage mechanisms that enable offline operation.
PWAs intersect directly with web app development services but are architecturally distinct from both fully native applications and traditional responsive websites.
How it works
The PWA model rests on three interlocking technical components operating in sequence:
-
HTTPS delivery — All PWA assets are served over a secure connection, satisfying the browser's baseline security requirement for Service Worker registration. HTTP-only origins cannot register Service Workers.
-
Service Worker registration and lifecycle — A Service Worker is a JavaScript file that runs in a background thread, separate from the main browser context. On first visit, the browser installs and activates the worker. Subsequent requests pass through the worker's
fetchevent handler, allowing the application to serve cached responses when the network is unavailable. The W3C Service Workers specification defines four lifecycle states: parsed, installing, installed/waiting, and activated. -
Web App Manifest declaration — A JSON file linked in the document
<head>declares metadata:name,short_name,icons(minimum 192×192px and 512×512px variants),start_url,displaymode (standalone,fullscreen,minimal-ui, orbrowser), andtheme_color. When all criteria are met, Chromium-based browsers trigger an install prompt; Safari on iOS requires manual add-to-home-screen.
Offline functionality in PWAs depends on caching strategy selection. The offline-functionality-in-apps reference covers the four principal strategies — Cache First, Network First, Stale-While-Revalidate, and Cache Only — each with distinct tradeoffs for content freshness versus availability.
Push notifications in PWAs are handled through the Push API and Notifications API, both W3C specifications. Safari added Web Push support for PWAs on macOS in Safari 16 (released 2022) and for iOS home screen PWAs in Safari 16.4 (released March 2023), closing a long-standing feature gap documented in the WebKit Feature Status tracker.
The app development technology stack selected for a PWA project determines which framework — React, Angular, Vue, or plain JavaScript — handles the application layer, while Workbox (a Google-maintained open-source library, documented at developer.chrome.com/docs/workbox) abstracts Service Worker complexity.
Common scenarios
PWAs demonstrate measurable advantage in specific deployment contexts:
- Content-driven media and publishing platforms where offline reading, fast repeat loads, and low data usage are priorities. The Service Worker caching model reduces repeat-visit load times by serving assets from the local cache rather than the network.
- E-commerce storefronts targeting markets with unreliable mobile connectivity. Ecommerce app development projects serving regions with 3G-dominant networks benefit from PWA asset caching and background sync for cart persistence.
- On-demand service applications with lightweight interaction models. On-demand app development scenarios involving service browsing, booking, and status tracking — without complex hardware integration — are well-served by PWA architecture.
- Internal enterprise tools distributed across a workforce without managed device enrollment, where app store distribution creates operational friction. Enterprise app development teams often deploy PWAs as intranet dashboards, field data collection tools, and HR self-service portals.
- MVP validation builds where speed to market and cross-platform coverage outweigh depth of native integration. MVP app development timelines are typically shorter for PWAs than for dual native builds, since a single codebase serves iOS, Android, and desktop.
Decision boundaries
The choice between a PWA and a native or cross-platform native build is governed by capability requirements, distribution model, and monetization structure.
PWA is the appropriate architecture when:
- The application does not require access to APIs unavailable in the browser context (ARKit/ARCore, advanced motion sensors, background location at OS level, in-app purchase APIs)
- Distribution outside app store review processes is acceptable or preferred
- The development budget constrains a dual-platform native build
- The target audience skews toward desktop or Android, where PWA support is most mature
Native or cross-platform native build is required when:
- The app monetization model depends on App Store or Google Play in-app purchase infrastructure, which PWAs cannot access
- The application requires deep iOS integration — HealthKit, Apple Pay in-app (distinct from web), background audio, or CarPlay
- App store optimization and store discoverability are primary acquisition channels
- Hardware integrations such as wearable and IoT device pairing demand Bluetooth LE central mode or ANT+ protocols with OS-level access
The Safari limitation is the most operationally significant boundary: iOS Safari does not support the Background Sync API, the Periodic Background Sync API, or the full Push API feature set outside of home screen installation. Applications requiring reliable background data synchronization on iOS must use a native runtime. The app security best practices profile also differs — native apps can leverage iOS Secure Enclave and Android StrongBox Keymaster for cryptographic key storage, capabilities not accessible from the browser context.
App scalability planning considerations apply equally to PWAs: the backend architecture — API design, database sharding, CDN strategy — is independent of the client application model.