Progressive Web Apps: What They Actually Are and When They Make Sense
Progressive Web Apps get described in two ways: either as the future of mobile development that will replace native apps, or as a niche technology that only a handful of companies actually need. Neither framing is useful.
PWAs are a set of web technologies that make websites behave more like native apps. Whether that matters for your project depends entirely on what you are building and for whom.
What Makes a Web App "Progressive"
A Progressive Web App is a web application that meets a specific set of criteria:
Service Worker. A JavaScript file that runs in the background, separate from the main browser thread. Service workers enable offline functionality by caching resources, background sync, and push notifications. This is the core technical component that makes PWAs possible.
Web App Manifest. A JSON file that tells the browser how to display your app when installed -- the app name, icon, theme color, and display mode (whether to show browser UI or run fullscreen). This is what allows users to "install" a PWA to their home screen.
HTTPS. Service workers require a secure context. PWAs must be served over HTTPS, which is standard practice for any modern site anyway.
Responsive Design. PWAs should work across all screen sizes. Not a new requirement -- just a baseline expectation for any web application.
A site that meets these criteria and loads quickly can be installed on a user's device, run offline, and send push notifications -- all without going through an app store.
What PWAs Actually Enable
Installation. Users can add a PWA to their home screen. On Android, Chrome prompts for installation automatically when PWA criteria are met. On iOS, users install via the Share > Add to Home Screen option. Once installed, the app launches fullscreen without browser chrome, indistinguishable from a native app to most users.
Offline Functionality. Service workers cache assets and data. A well-designed PWA can work entirely offline for core functionality and sync changes when connectivity returns. This is the most technically valuable capability for the right use cases.
Push Notifications. PWAs can send push notifications on Android and desktop Chrome. iOS added limited push notification support in Safari 16.4 (March 2023). This was previously the feature that kept many businesses from choosing PWAs over native.
Performance. Service worker caching makes repeat visits extremely fast. Assets cached after the first visit load from local storage rather than the network on subsequent visits.
When PWAs Are the Right Choice
PWAs are well-suited for projects where:
Your users are primarily on the web anyway. If your audience discovers and uses your product primarily through browsers, a PWA extends that experience without requiring a separate native codebase.
Offline access matters. Field workers who need to log data without connectivity, travelers using the app on flights, users in areas with unreliable networks -- these use cases genuinely benefit from offline-first architecture.
Cross-platform reach is a priority over platform-specific features. One PWA codebase works on Android, iOS, Windows, and macOS. Two native app codebases (iOS + Android) require separate development, testing, and maintenance.
App store distribution is a bottleneck. PWAs bypass the app store review process entirely. Updates deploy instantly without review delays or store approval risk.
Your budget does not support two native codebases. A well-built PWA is significantly less expensive to build and maintain than separate iOS and Android apps.
Example projects well-suited for PWAs: E-commerce stores, news and media apps, productivity tools, booking systems, customer portals, field service tools.
When Native Apps Are the Better Choice
PWAs are not the right answer when:
You need deep platform integration. Augmented reality, advanced camera controls, Bluetooth peripheral access, NFC, health kit integration, Apple Pay on iOS -- these capabilities require native APIs that PWAs cannot fully access.
Your users expect native performance. For gaming, video editing, or any CPU-intensive application, native code performs better than JavaScript in a browser context.
iOS push notifications are critical. iOS push support in PWAs is limited to Safari 16.4+ and requires users to install the PWA first. Android Chrome has better PWA push support but iOS still lags.
App store presence is part of your go-to-market. App stores are discovery mechanisms. If your target users actively search for apps in the App Store or Play Store, absence from those listings is a visibility problem.
Your business model requires in-app purchases. Apple's 30% cut on in-app purchases is enforced for native apps; PWAs that process payments directly bypass it. This is both an advantage (no commission) and a distribution limitation (no App Store placement).
The Technical Reality for Most Web Teams
Building a PWA from an existing web application involves:
- Adding a Web App Manifest (30 minutes)
- Registering a Service Worker (a few hours for basic caching, longer for offline-first)
- Implementing a caching strategy for your specific content and data patterns
- Testing offline behavior across browsers and devices
For new projects, frameworks like Next.js, Nuxt, and Create React App have PWA plugins that handle the boilerplate. Workbox (from Google) provides a library for service worker strategies that covers most caching patterns without writing service worker code from scratch.
The scope depends almost entirely on how sophisticated the offline functionality needs to be. A simple "cache and serve" strategy takes a day. A full offline-first application with background sync and conflict resolution is a multi-week project.
Frequently Asked Questions
Do I need to build a separate PWA or can my existing website become one?
An existing responsive website can become a PWA by adding a service worker and manifest. The functional gap is in what the service worker caches and how it handles offline scenarios. A site that adds a manifest and basic service worker is technically a PWA but may not provide meaningful offline value depending on how the caching is configured.
Are PWAs good for SEO?
Yes. PWAs are standard web applications -- they are indexed by search engines the same way any website is. The performance improvements from service worker caching can actually benefit SEO by improving Core Web Vitals scores. There is no SEO penalty for PWA features.
What is the biggest limitation of PWAs today?
iOS support remains the most significant limitation. While PWA support has improved substantially since Safari 16.4, iOS PWAs still have restrictions on push notification delivery, background processing, and some hardware API access that Android does not. For audiences predominantly on iOS, evaluate these gaps carefully before choosing PWA over native.
The Decision Framework
Build a PWA when: your users are web-first, cross-platform reach matters, offline access adds value, and platform-specific native features are not required.
Build native when: you need deep OS integration, your users expect native-level performance, App Store presence is essential, or iOS-specific features are critical to your value proposition.
Build both when: you have significant revenue, a technical team to maintain two codebases, and genuinely different requirements for web and native contexts.
Marcus Reed is Senior Editor and Digital Strategist at High5Expert, with experience evaluating and building web applications across PWA and native architectures.
Discussion
9 commentsWe launched a PWA for our e-commerce store six months ago after evaluating native apps. The repeat visit performance is remarkable -- subsequent page loads are nearly instant from the service worker cache. Add-to-home-screen adoption is about 8% of mobile visitors, and those installed users convert at nearly double the rate of browser visitors.
Welcome aboard! We publish new guides every week. Glad you found this helpful!
The iOS push notification limitation is the one that kills PWAs for many projects I evaluate. Our audience is about 65% iOS. Until Apple provides reliable push support in installed PWAs, we are stuck building a native iOS app in parallel for notification functionality, which defeats much of the cost advantage.
We review and update our guides regularly to keep them current. This one was last updated recently, and we plan to add new sections as the landscape evolves. Bookmark it and check back!
iOS PWA push support improving in Safari 16.4 was significant, but you are right that 65% iOS with push as a core feature creates a real gap. The practical path for your use case is likely PWA for the web experience plus a lightweight native iOS app specifically for push notification delivery -- essentially using the native app as a notification wrapper. Not ideal, but it covers both distribution and notification requirements without duplicating the full application.
True
Question: we have an existing React web app. What is the realistic effort to add meaningful offline support -- not just the manifest, but actual offline functionality for our core workflows?
That's a great suggestion! We're exploring video content for our most popular guides. Stay tuned — it's on our roadmap.
Tom's answer below is accurate for the technical scope. The strategy question matters as much as the implementation: what does your user actually need to do offline? If they need to read data, stale-while-revalidate caching is relatively straightforward. If they need to create or modify data offline and have it sync later, background sync with conflict resolution adds significant complexity. Define the offline user stories first, then scope the technical work.
True
The app store distribution bypass is undervalued. We had a native app that went through three rounds of App Store review for a single update because of an edge case in their payment guidelines. Switched to PWA. Updates deploy in minutes. No review queue, no interpretation of ambiguous guidelines.
Great question! You can bookmark our blog page — we publish new content regularly. We're working on a newsletter feature that will be available soon!
The App Store review cycle is a real operational cost that does not show up in the initial build estimate. Three rounds of review for a payment edge case is a scenario I have seen repeated across different clients. The review process has improved but it remains unpredictable for anything touching payments or user data policies. That unpredictability alone justifies PWA for update-heavy products that need to deploy quickly.
True
The performance gains from service worker caching on repeat visits are real. Before PWA: 2.8 second average load on repeat visits from mobile. After: 0.4 seconds. Users who visit regularly -- our best customers -- get a dramatically better experience. New visitors see the same performance as before; loyal ones see 85% faster loads.
That's the best compliment we can get! Glad it helped resolve the debate. Data-driven decisions are always the way to go.
For the offline React app question: Workbox is the right starting point. The stale-while-revalidate strategy handles most read-heavy workflows well. Offline writes with background sync add significant complexity -- plan for several days of work and thorough testing across connection states. Simple caching is a day; proper offline-first is a week or more.
Thank you! We do offer consulting and implementation services. Feel free to reach out through our contact page and we can discuss your specific needs.