Progressive Web Apps: When a Website Can Replace a Native App

Your users are not going to download another app. The average smartphone user downloads zero new apps per month. Meanwhile, they open their browser dozens of times a day. Progressive Web Apps sit at the intersection of these two realities: they live on the web but behave like native apps — installable, offline-capable, and fast.

This is not a new idea, but it has matured considerably. The question is no longer whether PWAs work. The question is whether a PWA is the right choice for your specific product.

What Is a Progressive Web App?

A Progressive Web App is a web application that uses a combination of modern browser APIs to deliver experiences that previously required a native app. The term was coined by Google engineers Alex Russell and Frances Berriman in 2015, though the underlying technologies have evolved significantly since then.

The defining characteristics of a PWA are reliability (loads instantly, even on unreliable networks), speed (responds quickly to user interactions), and engagement (feels like a native app, can be added to the home screen, receives push notifications).

What makes a web app "progressive" is that these capabilities are layered on top of a functioning web application. A user on an older browser still gets the web app. A user on a modern browser gets the enhanced experience. This is progressive enhancement applied at the platform level.

PWAs are not a single technology. They are a set of techniques and APIs used together. The three foundational pieces are service workers, the web app manifest, and HTTPS.

Core PWA Technologies

Service Workers

A service worker is a JavaScript file that runs in a background thread, separate from the main browser thread. It acts as a programmable network proxy, intercepting requests between the browser and the network.

This is what enables offline functionality. When a user first visits a PWA, the service worker caches critical assets — HTML, CSS, JavaScript, images. On subsequent visits, the service worker can serve those assets directly from the cache, bypassing the network entirely. The user gets a near-instant load even with no connection.

Service workers also enable background sync. If a user performs an action while offline — submitting a form, adding an item to a cart — the service worker queues that action and syncs it when the connection returns. The user experience is continuous; the network interruption is invisible.

Cache strategies are configurable. Cache-first works well for static assets that rarely change. Network-first works for content that must be fresh. Stale-while-revalidate serves cached content immediately while fetching an updated version in the background. Choosing the right strategy for each resource type is one of the more nuanced aspects of PWA development.

Web App Manifest

The web app manifest is a JSON file that describes your application to the browser. It specifies the app name, icons, theme colors, display mode, and start URL. When the manifest is present and the app meets certain criteria, browsers can prompt users to install the app to their home screen.

{
  "name": "My Application",
  "short_name": "MyApp",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#000000",
  "icons": [
    {
      "src": "/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ]
}

The display property controls how the app appears when launched from the home screen. standalone removes the browser UI, making the app look and feel like a native application. fullscreen goes further, hiding even the status bar on some platforms.

The manifest also controls the splash screen shown during launch, the orientation behavior, and whether the app appears in the app drawer on Android. A well-configured manifest is the difference between an app that feels native and one that clearly feels like a website in a wrapper.

HTTPS Requirement

Service workers and many other modern web APIs require HTTPS. This is a security requirement, not an optional best practice. A service worker can intercept all network requests from your app, which makes a compromised service worker on an HTTP site dangerous. HTTPS ensures the service worker itself cannot be tampered with in transit.

For most teams, HTTPS is already standard. Free certificates from Let's Encrypt have removed cost as a barrier. If you are building a new application, HTTPS should be the default from day one.

Push Notifications

The Web Push API allows PWAs to send notifications to users even when the app is not open, using the same notification infrastructure as native apps. The flow involves the user granting permission, the browser registering a push subscription with a push service, and your server sending messages to that push service.

On Android, web push notifications are nearly indistinguishable from native app notifications. On iOS, Apple added web push support in iOS 16.4, released in 2023, but only for PWAs that have been added to the home screen. This was a significant limitation for years and is worth understanding for your target audience.

Benefits of PWAs

No App Store Gatekeeping

Native app distribution runs through Apple's App Store and Google Play. Both charge annual developer fees. Both have review processes that can take days or weeks and can reject your app for reasons that are difficult to appeal. Both take a percentage of in-app purchases.

PWAs are distributed via URL. You update your app by deploying to your server. There is no review process, no approval wait, no fee per platform. For enterprise applications, internal tools, and products where you control the distribution channel, this is a significant operational advantage.

One Codebase for All Platforms

A PWA is a web application. It runs in any browser, on any device, with a single codebase. You are not maintaining separate iOS and Android codebases, separate release schedules, or separate developer teams with different skill sets.

This is not unique to PWAs — any web application runs cross-platform. What PWAs add is the ability to deliver a native-quality experience from that single codebase, without sacrificing platform reach.

Dramatically Smaller Footprint

The size difference between a PWA and its native equivalent can be stark. The Starbucks PWA is 233KB. The native Starbucks iOS app is 148MB. That is a 600x size difference. For users in markets with expensive data plans or limited device storage, this is not a minor detail — it is the difference between using your product and not.

Smaller size also means faster first load, which directly affects conversion rates. Google's research consistently shows that as page load time increases from one second to ten seconds, the probability of a user bouncing increases by 123%.

Instant Updates

When you deploy an update to a PWA, every user gets the update the next time they open the app. There is no waiting for users to accept an App Store update. There is no fragmentation across versions. If you discover a critical bug or need to push a security fix, you push it once and it is done.

For teams running A/B tests or iterating rapidly on product features, this is a meaningful operational advantage over native apps.

SEO and Discoverability

PWAs are web pages. Search engines crawl them, index them, and rank them. Your app content is discoverable through organic search without any additional work. This is not true of native apps, whose content is opaque to search engines.

For content-heavy products — media sites, e-commerce, documentation platforms — the SEO implications are significant. Users can land on a specific product page or article from a search result and get the full app experience, including the option to install.

Linkability

Any state in a PWA can be represented as a URL and shared. A user can send a link to a specific product, article, or feature to someone else, and that person lands directly in context. Native apps require deep link configuration, universal links on iOS, and app links on Android — all of which require ongoing maintenance and can break.

Real-World PWA Success Stories

The business case for PWAs is well-documented at scale.

Pinterest rebuilt their mobile web experience as a PWA after finding that only 1% of mobile web users converted to app users. After launching the PWA, they saw a 60% increase in core engagements, a 44% increase in user-generated ad revenue, and a 40% increase in time spent on the site.

Starbucks launched a PWA to provide an ordering experience for users on poor connections, particularly relevant internationally. They saw 2x daily active users and found that desktop users of the PWA were ordering at nearly the same rate as mobile users.

Uber built their PWA, m.uber.com, specifically for emerging markets with slow and unreliable connections. It loads in 3 seconds on 2G networks. The core booking flow is under 50KB. Users in markets where the native app was impractical due to data costs or device limitations could now use Uber through the browser.

Twitter Lite, Twitter's PWA, delivered a 65% increase in pages per session, a 75% increase in tweets sent, and a 20% decrease in bounce rate compared to the previous mobile web experience. Data usage dropped by 70%.

These are not edge cases. They are large consumer products where the PWA produced measurable, significant improvements in the metrics that matter.

PWA vs Native App vs Hybrid App

| Factor | PWA | Native App | Hybrid App | |---|---|---|---| | Development cost | Low (single codebase) | High (per platform) | Medium | | Time to market | Fast | Slow | Medium | | Performance | Good | Excellent | Good | | Hardware access | Limited | Full | Near-full | | App store presence | No (unless wrapped) | Yes | Yes | | Offline capability | Yes (service worker) | Yes | Yes | | Push notifications | Yes (limited on iOS) | Yes | Yes | | Update deployment | Instant | Requires store approval | Requires store approval | | Bundle size | Very small | Large | Medium | | SEO | Yes | No | No | | Installation | Browser prompt or URL | App store | App store |

Our web development services cover PWA architecture decisions in depth. For teams deciding between PWA and native, our mobile app development team can walk through the trade-offs specific to your product.

Limitations of PWAs

PWAs are not the right answer for every product. Understanding the limitations is as important as understanding the benefits.

iOS Restrictions

Apple has historically been the primary constraint on PWA capabilities. For years, iOS did not support web push notifications at all, which was a dealbreaker for any app where push engagement was core to the product. Apple added web push support in iOS 16.4 in 2023, but it requires the PWA to be installed to the home screen — background push to Safari tabs is not supported.

Storage limits on iOS are also more aggressive than on Android. iOS may purge service worker caches for PWAs that have not been opened recently. For apps where reliable offline functionality is critical, this is a real concern.

If your user base skews heavily iOS and your product depends on push notifications or aggressive offline functionality, test on real iOS devices early. Do not assume that what works on Android will work identically on iOS.

Hardware API Gaps

Native apps have access to the full hardware surface of the device: NFC, Bluetooth, advanced camera controls, accelerometer, gyroscope, ambient light sensors, and more. PWA access to hardware APIs has improved significantly — Web NFC and Web Bluetooth exist — but they are not universally supported across browsers and platforms.

If your product requires NFC for payment processing, Bluetooth for device pairing, or advanced sensor access, a PWA may not be technically sufficient regardless of its other advantages.

App Store Presence

In some markets and user demographics, the App Store or Google Play is the primary way users discover new applications. If your go-to-market strategy depends on app store optimization, featured placement, or search within those marketplaces, a PWA does not provide that surface by default.

There are tools like PWABuilder that can wrap a PWA into a native app shell for store submission, but this adds complexity and partially defeats the operational simplicity that makes PWAs attractive.

Animation and Complex UI Performance

For applications with complex animations, physics simulations, or high frame-rate interactions, native still has an edge. Native apps have direct access to platform animation APIs and GPU acceleration in ways that web rendering pipelines do not yet fully match. Games, creative tools, and applications where fluid animation at 60fps is a core product requirement will generally be better served by native development.

When to Build a PWA

Content-heavy applications: News sites, documentation platforms, blogs, media streaming. The SEO benefits alone often justify the PWA approach, and the offline caching makes content available on unreliable connections.

E-commerce: Fast load times and offline browsing directly impact conversion. Pinterest and major retailers have demonstrated the business case. See our work in ecommerce development for more on this.

Internal tools and enterprise applications: No app store friction, instant updates, cross-platform from a single codebase. For tools used on corporate devices or in-browser environments, PWAs are often the most pragmatic choice.

Emerging markets: Users in markets with expensive data, lower-end devices, and unreliable connections benefit disproportionately from PWA characteristics. If your expansion strategy includes Southeast Asia, Latin America, or Sub-Saharan Africa, a PWA built for low-bandwidth conditions is not just a nice-to-have.

When you have a web app and need to extend its reach: If you already have a responsive web application, adding PWA capabilities is incremental work. You are not rebuilding — you are adding a service worker and a manifest to something that already exists.

When Not to Build a PWA

Heavy hardware access: If your product requires Bluetooth pairing, NFC transactions, advanced camera features, or other low-level hardware integration, start with native. The hardware API gaps in PWAs are real and will require workarounds that compromise the user experience.

Complex animations and games: Graphics-intensive games, AR/VR applications, and products where 60fps animation is a non-negotiable product requirement belong on native platforms where they have direct access to rendering APIs.

App store presence is a strategic requirement: If your distribution strategy depends on App Store Search, featuring, or ratings-driven social proof, a PWA does not solve that problem without an additional wrapper that adds its own complexity.

Platform-specific features are core: Apple Pay on iOS, Google Pay integration at the system level, widget support, and deep OS integration like Shortcuts or Live Activities are native features that PWAs cannot access.

How to Build a PWA

Building a PWA is incremental. You do not need to start over.

Step 1: Start with a responsive web application. If you are using React, this means a well-structured component architecture, good performance fundamentals, and responsive layouts. Our React guide covers the foundation. The PWA layer sits on top of a well-built web application — it does not compensate for a poorly built one.

Step 2: Add a service worker. For most teams, using a library like Workbox (maintained by Google) is the pragmatic approach. Workbox handles the complexity of cache strategy configuration and service worker lifecycle management. Start with a simple caching strategy for static assets, then layer in more sophisticated strategies for dynamic content.

Step 3: Add a web app manifest. Create the JSON manifest file, generate icons in the required sizes, and link the manifest from your HTML. The install prompt will appear automatically on Android once the manifest is present and certain engagement heuristics are met. On iOS, users can manually add to home screen from the share menu.

Step 4: Test with Lighthouse. Google's Lighthouse tool, built into Chrome DevTools, audits PWA compliance alongside performance, accessibility, and SEO. It will surface any missing pieces — no manifest, no service worker, missing icon sizes, non-HTTPS responses — and give you a clear checklist to completion.

Step 5: Test on real devices. PWA behavior varies across browsers and operating systems. Test the install flow on Android Chrome, iOS Safari, and desktop Chrome. Test offline behavior by throttling the network in DevTools and by putting a real device in airplane mode. The service worker cache behavior you see in the browser simulator is not always what happens on a real device.

The comprehensive PWA documentation at web.dev and MDN covers the technical implementation in depth. Both are authoritative, current resources maintained by the teams building the underlying platform APIs.

The Decision Framework

The right question is not "PWA or native?" The right question is "what does my product actually require?"

If your product is primarily content, transactions, or information exchange — and if your users are finding you through search or direct links — a PWA will serve you well. The development cost is lower, the deployment is simpler, the SEO is better, and the real-world performance data from companies like Pinterest, Starbucks, and Uber is compelling.

If your product requires deep hardware integration, depends on app store distribution as a growth channel, or demands animation fidelity that only native can deliver, build native. The PWA advantages do not outweigh a product that cannot do what it needs to do.

For many teams, the answer is to build the PWA first. Ship faster, iterate based on real user behavior, and invest in native development if and when you hit the ceiling of what the web platform can deliver. Given that ceiling keeps rising — and given that most products never actually reach it — the PWA-first approach is increasingly the rational default.

If you are evaluating whether a PWA, a native app, or a React Native vs Flutter hybrid approach is right for your product, the details of your use case matter more than any general recommendation. The technologies are mature. The question is fit.