What is a Progressive Web App?

Your website can behave like a native app, work offline, send push notifications, and sit on a user’s home screen without a single app store submission.

That’s exactly what a progressive web app does. It uses standard web technologies, including HTML, CSS, and JavaScript, to deliver an app-like experience directly through the browser.

Businesses like Starbucks, Twitter, and Pinterest have deployed PWAs and seen measurable gains in engagement, load speed, and conversion rates.

This guide covers what a PWA is, how the core technologies work, how it compares to native apps, and what the real limitations are before you build one.

What is a Progressive Web App?

A progressive web app (PWA) is a web application built with standard web technologies, including HTML, CSS, and JavaScript, that delivers an app-like experience directly through a browser.

PWAs run on a web server and are accessed via URL, just like any website. The difference is that they use modern browser APIs to support offline functionality, push notifications, home screen installation, and background sync without requiring a download from an app store.

The term was coined in 2015 by designer Frances Berriman and Google Chrome engineer Alex Russell to describe web apps that take advantage of new browser capabilities, specifically service workers and web app manifests.

PWAs work across all major operating systems and device types through a single codebase. A user on Android, iOS, Windows, or macOS accesses the same application. This cross-platform compatibility is one of the primary reasons businesses choose PWAs over separate native builds.

The global PWA market was valued at USD 2.08 billion in 2024 and is projected to reach USD 21.24 billion by 2033, growing at a CAGR of 29.9% (Grand View Research).

What Technologies Make a Progressive Web App Work?

3 core technologies define PWA functionality: a service worker, a web app manifest, and HTTPS. Remove any one of them and the app no longer qualifies as a PWA.

These components are not separate features. They interact directly. The service worker handles caching and offline delivery. The manifest defines how the app appears when installed. HTTPS is the security layer required for service worker registration to work in the first place.

What Does a Service Worker Do?

Background script that intercepts network requests:

• Runs separately from the main browser thread in a dedicated JavaScript file
• Intercepts every fetch request the app makes to the server
• Applies a caching strategy (cache-first or network-first) to decide whether to serve from cache or fetch fresh data
• Handles push notifications, background sync, and offline fallback pages

Service workers have a defined lifecycle: install, activate, and fetch. During the install phase, the worker caches the app shell and critical assets. During fetch events, it decides which response to return based on the chosen strategy.

Firefox added service worker support in 2016. Safari and Microsoft Edge followed in 2018. As of September 2025, Firefox version 143 added full PWA support on Windows (Wikipedia).

What is a Web App Manifest?

The web app manifest is a JSON file, typically named manifest.json or app.webmanifest, that tells the browser how to present the app when installed.

Required manifest fields for installability:

• name or shortname: The app name shown on the home screen and in the title bar
• starturl: The page that loads when the app is launched from the home screen
• display: Set to standalone, fullscreen, or minimal-ui to remove browser chrome
• icons: Must include both 192px and 512px versions (W3C specification)

The manifest links to the HTML via a <link rel="manifest"> tag and must be present on every page from which the PWA can be installed (web.dev, 2024).

What Are the Core Features of a Progressive Web App?

PWAs expose browser capabilities that traditional websites cannot access. These features are what separate a PWA from a standard front-end web build.

Offline Functionality

Service workers store assets in the browser’s Cache Storage API. When a user goes offline, the worker intercepts requests and returns cached responses instead of failing.

2 common strategies are used: cache-first (serve from cache, fall back to network) and network-first (fetch fresh data, fall back to cache). The right choice depends on how frequently content changes.

Starbucks’ PWA uses a cache-first strategy for the menu and order UI. The entire app is only 233 KB, compared to 148 MB for the native iOS app, and still supports full offline beverage configuration (Formidable Labs).

Push Notifications

PWAs send push notifications through the Web Push API without requiring a native app to be installed.

The service worker listens in the background, receives push messages from the server, and displays them as system notifications. Twitter’s PWA sends more than 10 million push notifications per day (SimiCart).

iOS push notification support for PWAs arrived in iOS 16.4 (2023). Before that update, push was Android-only, which limited PWA viability for iOS-first audiences.

Home Screen Installation

When a PWA meets installability criteria, the browser triggers a prompt allowing users to add the app to their device’s home screen.

Behavior varies by platform:

• Chrome on Android fires an automatic beforeinstallprompt event
• iOS requires a manual action through the Safari share menu
• Desktop Chrome and Edge show an install icon in the address bar

Once installed, the app launches in standalone mode, removing all browser chrome, and appears in the device’s app switcher alongside native apps (MDN, 2025).

Background Sync

Background sync defers data submission until the device has a stable connection.

If a user submits a form or completes an order while offline, the service worker stores the request and retries it automatically when connectivity returns. This removes the failure state that standard web forms produce when the network drops mid-submission.

How Does a Progressive Web App Differ from a Native App?

The differences fall into 3 categories: development cost, distribution, and hardware access.

Development and Maintenance

A native app requires separate codebases for iOS and Android. A PWA uses one codebase that runs across all platforms.

According to a Clutch survey (2023), a simple native app costs between USD 25,000 and USD 100,000 per platform. A comparable PWA can be built at a fraction of that cost, and updates deploy automatically via the server without app store review cycles.

PWA development costs are typically 40-60% lower than building equivalent native apps for both major platforms (XICTRON, 2026).

Distribution

Native apps go through Apple’s App Store or Google Play review process. PWAs are accessed via URL and can be installed directly from the browser.

Key distribution differences:

• PWAs bypass app store approval delays and revenue share requirements
• Updates go live instantly with no store submission
• PWAs can also be listed in the Google Play Store (via Trusted Web Activity), Microsoft Store, and Samsung Galaxy Store
• Apple’s App Store accepted PWA submissions starting with iOS 18 support for third-party PWA stores

Hardware Access Limitations

Native apps access hardware APIs that PWAs currently cannot reach on all platforms.

PWAs lack access to Bluetooth, NFC, ARKit, in-app purchase systems, and advanced camera controls on iOS. Android Chrome supports more hardware APIs than iOS Safari, which creates inconsistent cross-platform functionality for hardware-dependent use cases.

This is the primary reason some companies build a PWA first, then add a native wrapper if specific hardware features become necessary.

What Are the Performance Benchmarks of Progressive Web Apps?

PWA performance gains come from 2 sources: service worker caching reduces repeat-visit load times, and the reduced payload size (no app store overhead) improves first-load speed on low-bandwidth networks.

Load Time and Core Web Vitals

PWAs have shown an average loading time of under 2 seconds, compared to abandonment rates that spike at the 5-second mark (Statista, 2023).

Service worker caching directly affects Time to Interactive (TTI) by serving pre-cached assets rather than waiting on network responses. This has the most impact on repeat visits, where the cache-first strategy returns content nearly instantly.

Forbes rebuilt their site as a PWA and achieved a page load time of 0.8 seconds, a 43% increase in sessions per user, and a 20% increase in impressions (VisionVix).

Engagement and Conversion Data

Real-world deployment data across multiple industries shows consistent engagement gains after PWA launches:

• Pinterest: 40% increase in time spent on site, 44% increase in ad revenue (SimiCart)
• Alibaba: 76% increase in total conversions across browsers (web.dev)
• Trivago: 150% increase in engagement after reducing load times to under 1.5 seconds (Google)
• Flipkart: 3x increase in time on site, 70% boost in conversion rates (VisionVix)

PWAs experienced a 70% increase in session length and a 20% increase in page views per session compared to traditional web apps (Straits Research, 2025).

Payload Size Comparison

Install size is where PWAs have a clear technical advantage over native apps.

Twitter’s PWA occupies only 600 KB versus 23.5 MB for the native Android app. Uber’s PWA loads in under 3 seconds on 2G networks and comes in at just 50 KB. These size differences matter most in emerging markets where low-end devices and limited data plans are common.

Which Brands Have Deployed Progressive Web Apps?

PWA adoption is strongest in e-commerce, social media, and services with global emerging-market audiences. The 4 most-referenced deployments all share one characteristic: measurable business improvement within months of launch.

Twitter Lite

Twitter Lite launched in 2017 and was designed for users on 2G and 3G networks in markets like India, Indonesia, and Nigeria.

Results after launch: 65% increase in pages per session, 75% more tweets sent, and a 20% reduction in bounce rate (Google case study). The PWA reduced data usage by 70% compared to the standard app and enabled 250,000 unique daily users to run Twitter from their home screen an average of 4 times per day (SimiCart).

Starbucks

Starbucks’ PWA supports full offline ordering. Users browse the menu, customize drinks, and save orders without a network connection. The app syncs when connectivity returns.

At 233 KB, the Starbucks PWA is 99.84% smaller than the native iOS app (148 MB). Daily active users doubled after launch, and desktop order rates reached near-parity with mobile (pwastats.com).

Pinterest

Pinterest rebuilt their mobile web experience as a PWA after identifying slow load times as the primary cause of mobile user drop-off.

Post-launch results: 60% increase in user engagement, 44% increase in ad revenue, and a 40% reduction in perceived load time (SimiCart). Core Web Vitals improvements drove the majority of the engagement gain.

Uber

Uber’s PWA, known internally as m.uber, loads in 3 seconds on 2G networks and targets riders on low-end devices not supported by the native app.

At 50 KB, it is one of the smallest functional ride-booking interfaces deployed at scale. The use of a cache-first strategy and minimal JavaScript dependency keeps it fast on constrained hardware.

What Are the Requirements to Build a Progressive Web App?

A web app must meet 4 baseline technical requirements before any browser treats it as a PWA and enables installation.

The 4 mandatory requirements are: HTTPS, a registered service worker, a valid web app manifest, and a responsive layout.

HTTPS

HTTPS is a non-negotiable baseline. Service workers cannot be registered on HTTP origins.

This requirement exists because service workers intercept all network requests from the app. Running that capability over an unencrypted connection would allow man-in-the-middle attacks to inject malicious responses into the cache. Localhost is exempt during development, but any production deployment requires a valid TLS certificate (Microsoft Edge documentation).

Service Worker Registration

The service worker file must be registered from the app’s JavaScript and must include at least one event handler.

Minimum service worker requirements:

• The file must be served from the same origin as the app
• Must handle the install event and cache at least a basic offline fallback
• Must handle fetch events to intercept network requests

Google’s Workbox library abstracts service worker complexity into pre-built caching strategies. Most production PWAs use Workbox rather than writing raw service worker logic from scratch.

Valid Web App Manifest

The manifest file must include 5 properties for Chrome to consider the app installable: name or shortname, starturl, display, and icons at both 192px and 512px (W3C specification).

A maskable icon variant is also required to pass a full Google Lighthouse audit. Without it, the icon may appear with a white background on Android home screens that use adaptive icon shapes.

Responsive Design

A PWA must work across viewport sizes without horizontal scrolling or broken layouts.

This is enforced through media queries and a responsive design approach. The viewport meta tag must be set correctly in HTML. A PWA that breaks on a 320px screen fails the mobile-first design requirement and will not pass a Lighthouse PWA audit.

How Do Progressive Web Apps Affect SEO?

PWAs do not get automatic SEO benefits from the manifest file or service worker. Rankings improve indirectly through faster load times, better Core Web Vitals scores, and reduced bounce rates.

The SEO risks come from the architecture. PWAs built as single-page applications often serve near-empty HTML at the initial request, with content injected by JavaScript after the page loads. Googlebot processes that JavaScript in a deferred second wave, which delays indexing (Google Search Central, 2024).

How Googlebot Crawls PWA Content

Two-wave indexing process:

• Wave 1: Googlebot fetches the initial HTML and indexes any server-rendered content immediately
• Wave 2: Googlebot returns later to execute JavaScript and index dynamically generated content

The delay between waves can last hours or days. Pages that only exist after JavaScript execution may be indexed late or not at all.

Onely research shows Google needs 9 times longer to crawl JavaScript-powered sites compared to plain HTML. For large PWAs, that crawl budget gap directly reduces how many pages get indexed per day.

Service Worker Caching and Crawler Risk

Googlebot does not execute service workers during crawling (Google Web Rendering Service documentation). Any content served exclusively through service worker cache logic is invisible to the crawler.

A misconfigured service worker can serve a cached app shell to Googlebot instead of full page content. The crawler indexes an empty frame. Rankings drop, and the cause is hard to trace without active monitoring of rendered output (Studio Ubique, 2024).

3 practices that protect crawlability:

• Use server-side rendering (SSR) or pre-rendering so Googlebot receives full HTML on first request
• Avoid JavaScript-inserted internal links since Googlebot only follows standard a href anchor tags
• Monitor Google Search Console for new “Discovered, currently not indexed” entries after every deployment

Core Web Vitals and Page Experience Signals

Service worker caching improves Largest Contentful Paint (LCP) and Time to Interactive (TTI) on repeat visits by serving pre-cached assets. Both metrics feed directly into Google’s Page Experience ranking signals.

Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. PWAs must maintain responsiveness throughout the full page lifecycle, not just on first interaction (Chrome for Developers, 2024).

Google’s 53% mobile abandonment threshold at 3-second load times makes service worker caching a practical ranking lever, not just a user experience improvement (Google).

What Are the Limitations of Progressive Web Apps?

PWA limitations split into 2 categories: platform restrictions set by Apple, and structural gaps that affect discoverability and hardware access across all platforms.

iOS Safari Restrictions

Push notifications on iOS required home screen installation before arrival in iOS 16.4 (March 2023). That is a decade later than Safari for macOS, which gained push support in 2013 (BigGo, 2024).

Active iOS restrictions as of 2025:

• No background sync, meaning offline-queued actions only sync when the app is open
• Cache API limited to approximately 50 MB per origin, compared to Chrome’s higher quotas
• Data stored in Safari does not share with the installed PWA instance, creating separate storage contexts
• Storage cleared after 7 days of inactivity if the PWA is not added to the home screen

In March 2024, Apple removed standalone PWA mode for EU users under iOS 17.4 to comply with the Digital Markets Act. All PWAs in EU countries reverted to opening in Safari tabs with no push support (MagicBell, 2024). After developer backlash, Apple partially reversed the change.

App Store Discoverability Gap

PWAs do not appear in the Apple App Store or Google Play Store search results by default. Users discover them through web search, direct links, or marketing, not through app browsing behavior.

The install friction gap is real. iOS requires a manual 4-tap process through Safari’s share menu. Android Chrome fires an automatic prompt. That gap in install rates affects usability and user adoption numbers, especially in markets where the App Store is the primary app discovery channel.

Chrome leads PWA capability scoring with 97 out of 100 across 14 PWA capability categories. Safari scores 86, with the largest gaps in background capabilities and hardware device access (BigGo browser scorecards, 2024).

Hardware API Gaps

PWAs lack access to 4 hardware capability categories on iOS: Bluetooth, NFC, ARKit, and advanced camera controls.

Web Bluetooth and Web NFC are available in Chrome on Android but blocked entirely on iOS Safari. This rules out PWAs for IoT device management, contactless payment flows, and AR try-on features without native wrappers.

The decision framework is straightforward. Content-driven apps, catalog browsing, news, ordering, and internal tools all work well as PWAs. Anything that requires real-time hardware integration needs a native layer.

How is a Progressive Web App Installed on a Device?

Installation behavior differs significantly by browser and platform. There is no single install path that works identically on all devices.

Android Chrome Installation

Chrome on Android fires the beforeinstallprompt event automatically when the PWA meets installability criteria. The browser shows a bottom-sheet prompt asking the user to add the app to their home screen.

Chrome installability criteria (as of 2024):

• Valid web app manifest with name, starturl, display, and icons at 192px and 512px
• Registered service worker with a fetch event handler
• Served over HTTPS

Once installed, the app receives its own icon in the Android app drawer, appears in the system app switcher, and opens in standalone mode with no browser toolbar (MDN, 2025).

iOS Safari Installation

There is no automatic install prompt on iOS. The entire process is manual and requires the user to know it exists.

The steps: open Safari, tap the Share button, scroll to “Add to Home Screen,” tap it, and confirm. That is a minimum of 4 taps, compared to 1 on Android. Many iOS users are simply unaware the option exists (Vinova, 2025).

Since iOS 16.4, PWAs installed through this process can receive push notifications. Before that update, iOS PWAs had no push capability at all. As of iOS 26, every site added to the home screen defaults to opening as a web app, even without a manifest file (MobiLoud, 2026).

Desktop Installation

Google Chrome and Microsoft Edge on Windows, macOS, and Linux display an install icon in the address bar when a PWA meets installability criteria.

Desktop PWAs open in a standalone window separate from the main browser, with no address bar or browser tabs. They appear in the operating system’s app launcher alongside native apps. This behavior is consistent across Chrome and Edge on all supported desktop platforms (web.dev, 2024).

Safari on macOS added “Add to Dock” support in Safari 17 on macOS Sonoma. Firefox does not support PWA installation on desktop as of 2025, though Firefox 143 added PWA support on Windows in September 2025 (Wikipedia).

How Do You Test and Audit a Progressive Web App?

3 tools cover the full PWA testing workflow: Google Lighthouse for compliance auditing, Chrome DevTools for live inspection, and Workbox for service worker validation.

Google Lighthouse PWA Audit

Lighthouse is the standard compliance tool. It runs inside Chrome DevTools under the Lighthouse tab and audits 5 categories: Performance, Accessibility, Best Practices, SEO, and Progressive Web App.

Common failure points Lighthouse flags:

• Missing maskable icon in the manifest
• No offline fallback page when the service worker returns a network error
• HTTP to HTTPS redirect missing in production
• Invalid or missing starturl in the manifest

PWA auditing within Lighthouse is technically deprecated as of 2024. Google now directs developers to Chrome’s updated Installability Criteria documentation for the current compliance checklist (Chrome for Developers, 2024).

Chrome DevTools Application Panel

Lighthouse tells you what failed. DevTools shows you exactly what the service worker is doing in real time.

Application panel inspection workflow:

• Service Workers tab: check registration status, active state, and push subscription
• Cache Storage tab: inspect every cached URL and verify cache-first strategy is populating correctly
• Manifest tab: confirm all required fields are parsed without errors

PageSpeed Insights provides real-world Core Web Vitals data collected from Chrome users on the target URL. Unlike the lab data in Lighthouse, PageSpeed Insights reflects actual field performance across real devices and network conditions.

Workbox for Service Worker Testing

Workbox, developed by Google, is the standard library for building and validating service worker caching strategies in production PWAs.

It abstracts cache-first, network-first, and stale-while-revalidate strategies into pre-built modules, removing the need to write raw service worker logic from scratch. The workbox-background-sync module handles Background Sync API fallbacks for browsers that do not support the native API (Chrome for Developers, 2024).

The Workbox CLI wizard walks through service worker setup and generates the configuration file. Most production PWAs built with React, Angular, or Vue use Workbox under the hood, whether through next-pwa, Angular’s @angular/pwa schematic, or a custom Rollup build integration.

Testing for SEO Compatibility

Standard PWA auditing tools do not test for crawler rendering gaps. That requires a separate check.

Compare raw HTML against rendered output using Screaming Frog with JavaScript rendering enabled, or use Google Search Console’s URL Inspection tool to see exactly what Googlebot sees when it fetches a key page. Run these checks after every deployment that touches the service worker or the backend rendering configuration. Silent service worker misconfigurations are the most common cause of ranking drops after a PWA launch (Studio Ubique, 2024).

FAQ on Progressive Web Apps

What is a progressive web app?

A progressive web app is a web application built with HTML, CSS, and JavaScript that delivers an app-like experience through the browser. It supports offline access, push notifications, and home screen installation without requiring an app store download.

How does a progressive web app work?

It relies on 3 core technologies: a service worker that caches content and handles offline requests, a web app manifest that defines how the app appears when installed, and HTTPS for secure delivery.

What is the difference between a PWA and a native app?

A native app is downloaded from an app store and built separately for iOS and Android. A PWA runs from a single codebase in the browser, installs optionally, and costs significantly less to build and maintain.

Do progressive web apps work on iPhone?

Yes, with limitations. iOS Safari supports basic PWA features including offline access and home screen installation. Push notifications require iOS 16.4 or later. Background sync and some hardware APIs remain unavailable on iOS as of 2025.

Are progressive web apps good for SEO?

PWAs can help SEO indirectly through faster load times and better Core Web Vitals scores. However, JavaScript-rendered content carries indexing risk. Googlebot processes JavaScript in a deferred second wave, which can delay or prevent full page indexing.

What is a service worker in a PWA?

A service worker is a JavaScript file that runs in the background, separate from the main browser thread. It intercepts network requests, applies caching strategies, handles offline fallbacks, and enables push notifications and background sync.

Can a PWA replace a native app?

For content-driven use cases, ordering, news, and internal tools, yes. For apps requiring Bluetooth, NFC, ARKit, or in-app purchases, a native layer is still needed. Twitter, Starbucks, and Uber use PWAs as their primary mobile web experience.

What is a web app manifest?

A web app manifest is a JSON file that tells the browser how to display the installed app. It defines the app name, icons, start URL, and display mode. It must include 192px and 512px icons to meet Chrome installability criteria.

How do you install a progressive web app?

On Android Chrome, the browser shows an automatic install prompt. On iOS Safari, users tap Share then “Add to Home Screen” manually. On desktop, Chrome and Edge display an install icon in the address bar when criteria are met.

How do you test a progressive web app?

Run a Google Lighthouse audit inside Chrome DevTools to check installability, performance, and manifest validity. Use the Application panel to inspect service worker status and cache storage. PageSpeed Insights provides real-world Core Web Vitals field data.

Conclusion

This conclusion is for an article presenting what is a progressive web app, and the answer is straightforward: a single codebase that delivers offline functionality, push notifications, and home screen installation through standard browser APIs.

The service worker lifecycle, web app manifest, and HTTPS requirement are not optional extras. They are the technical baseline that separates a PWA from a regular responsive website.

Real deployments from Alibaba, Flipkart, and Trivago show consistent gains in session length, conversion rates, and cross-platform reach.

iOS Safari restrictions and the app store discoverability gap are real constraints. Plan around them, not past them.

If your audience is mobile-first and your use case is content delivery or transactional, a PWA is worth building.