What Progressive Web Apps Are
Progressive Web Apps (PWAs) are web applications that use modern browser APIs to provide app-like experiences — including offline functionality, push notifications, home screen installation, and device hardware access — that were previously available only to native applications installed through app stores. The term progressive reflects the design philosophy: the PWA works for every user on every browser, progressively enhancing the experience for users on browsers and devices that support the additional capabilities. The PWA accessed on a modern Chrome browser on Android can be installed to the home screen, receive push notifications, work offline, and access the camera and geolocation; the same PWA accessed on an older browser falls back to a capable but more limited web experience.
The PWA adoption that most clearly demonstrates the approach’s commercial viability: the large e-commerce and media companies that have rebuilt their mobile web experience as PWAs and documented significant business metric improvements. Twitter Lite, Starbucks, Pinterest, and others have published case studies showing improvements in engagement, conversion, and session duration after PWA adoption. Twitter Lite’s 2017 case study documented a 65% increase in pages per session and a 75% increase in tweets sent after replacing their mobile web experience with a PWA — demonstrating that the performance and engagement improvement of the PWA approach can produce measurable business outcomes comparable to or better than native app experiences for the right use cases.
The Technical Capabilities That Define PWAs
The browser APIs that most define the PWA capability set: the Service Worker API (the background JavaScript worker that enables offline functionality, background sync, and push notification receipt — the most fundamental PWA capability that enables the app to function when network connectivity is unavailable or poor), the Web App Manifest (the JSON file that enables the browser’s install prompt and controls how the PWA appears when installed on the home screen — defining the icon, the name, the splash screen, and the display mode), and the Push API (which enables the server to send notifications to the user’s device even when the PWA is not open — the capability that most bridges the engagement gap between web and native).
The PWA capability that has most expanded in recent years to close the gap with native apps: the access to device hardware and operating system features through progressive web APIs. The Web Bluetooth API that enables communication with Bluetooth devices, the Web Serial API that enables communication with serial port devices, the File System Access API that enables reading and writing files to the local file system, and the Web NFC API that enables NFC tag reading and writing are all capabilities that were previously unavailable to web applications. The browser’s progressive implementation of these APIs on Android and desktop has significantly expanded the range of applications that a PWA can provide, though iOS continues to lag behind Android in the breadth of APIs it exposes to PWAs.
PWA vs Native: When Each Approach Makes Sense
The application characteristics that most favour a PWA approach over native app development: the application that requires broad reach across platforms without the maintenance cost of separate iOS and Android codebases, the application where the target audience is likely to encounter the brand through web search (where a PWA can be discovered and used immediately without an app store download), and the application where the required device capabilities are available through browser APIs (so that the web platform’s hardware access limitations do not prevent the required functionality).
The application characteristics that most favour native app development over a PWA: the application that requires deep integration with platform-specific features (advanced AR capabilities, background processing in specific modes, always-on sensor access) that browser APIs do not fully expose, the application where the smoothest possible 60 or 120 frames per second animation and interaction are central to the user experience (where native rendering pipelines consistently outperform browser rendering for the most demanding interaction patterns), and the application where App Store distribution is valuable for discoverability among users who actively search the store for apps in the category.
Building a PWA: The Technical Requirements
The technical requirements that a web application must meet to qualify as a PWA and be eligible for the browser’s install prompt: serving the application over HTTPS (which is required for Service Worker registration and for the Push API), registering a Service Worker that handles fetch events (enabling at minimum a network-first strategy that falls back to cached content when offline), and providing a valid Web App Manifest with the required fields (name, icons of the required sizes, and a start URL). Meeting these minimum requirements produces the basic PWA; the full PWA experience adds offline caching strategies, push notification integration, background sync, and the device API integrations that the application’s specific use case requires.
The PWA development framework that most simplifies the implementation of Service Worker caching strategies: Workbox, the Google-developed library that provides pre-built implementations of the most common Service Worker caching patterns. The cache-first strategy (serving from cache and falling back to network, ideal for static assets that change infrequently), the network-first strategy (serving from network and falling back to cache, ideal for dynamic content where freshness matters), and the stale-while-revalidate strategy (serving from cache immediately while revalidating the cache in the background, ideal for frequently used but non-critical resources) are available as Workbox modules that can be composed into a Service Worker without implementing the caching logic from scratch.
The iOS PWA Situation
The PWA capability limitation that most affects PWA adoption for applications targeting iPhone users: Apple’s historically restrictive approach to PWA capabilities on iOS. Safari on iOS has been the laggard in implementing PWA APIs — Service Worker support was added in iOS 11.3 in 2018, but key capabilities including push notifications, background sync, and many hardware access APIs have been implemented later, more restrictively, or not at all compared to Chrome on Android. The push notification support that Android PWAs have had since 2015 was not added to iOS Safari until iOS 16.4 in 2023, and even the current implementation requires iOS 16.4 or later, which excludes a significant portion of the iPhone user base.
The EU Digital Markets Act impact on PWA capabilities in iOS: the DMA requirements that took effect in March 2024 required Apple to allow alternative browser engines on iOS within the EU — previously, all iOS browsers used Apple’s WebKit engine regardless of their brand. The alternative browser engines that developers can now ship on iOS within the EU may enable PWA capabilities that WebKit does not expose, potentially creating a bifurcated experience where EU iOS users can access more capable PWAs than users in other regions. The long-term impact of this regulatory change on PWA adoption and iOS browser diversity is still developing.
