Development
What Is a PWA? The Complete 2026 Guide to Progressive Web Apps
Rebuilding mobile experiences as a PWA allowed Twitter to increase engagement. Their customers started tweeting 75% more often, and bounce rate fell by 20%. For Pinterest, results were similar – users spent 40% more time in the app, core engagement grew by 60%, and revenue grew by 44%. Both companies achieved it without a single line of Swift or Kotlin code.
For most teams, there are two main options, and both of them are bad:
- Native – takes months of work, and, depending on the complexity, can cost from 50k to 250k
- Plain mobile web – fast to build, but has weak re-engagement loops, as it doesn’t have offline support, push notifications, and fewer habit-forming interactions compared to native apps
A Progressive Web App (PWA) combines the best of both options. After reading this guide, you’ll know what it is, its benefits, and when it doesn’t work for you. Additionally, we prepared the six steps necessary to create a PWA.
What is a Progressive Web App?
A Progressive Web App is a web application that delivers a native-like experience and is built using modern web standards. They are installable, offline-capable, push-enabled – without going through an app store.
In 2015, Frances Berriman (product designer) and Alex Russel (Google Chrome engineer) introduced this term to describe apps that progressively enhance themselves to feel more like native apps on capable devices while staying functional on older ones.
Three technical requirements separate a PWA from a regular website, meeting which ensures installability, offline capability, and the “Add to Home Screen” prompt:
- HTTPS. A secure context is required. Service workers won’t register without it
- Service worker. Background script that intercepts network requests, manages caching, and handles push events
- Web App Manifest. JSON file declaring name, icons, start URL, and display mode
PWA is a checklist, not a framework. You can build it with React, Vue, Angular, Svelte, or vanilla JS.
PWA vs. Responsive Web App vs. Native App
These three categories are often confused. They are related, but have significant differences.
| Feature | Responsive web | PWA | Native app |
|---|---|---|---|
| Distribution | Web URL | Web URL + installable | App Store / Play Store |
| Install friction | Zero | One tap | Multiple taps + review wait |
| Offline support | No | Yes (Service Worker) | Yes |
| Push notifications | Web push only | Yes (web push, incl. iOS 16.4+) | Yes |
| Home-screen icon | No | Yes | Yes |
| Hardware access | Limited | Partial (expanding via Project Fugu) | Full |
| Update mechanism | Instant on reload | Instant via Service Worker | App store review (1–7 days) |
| Dev cost | Low | Low–medium | High (per platform) |
| Time to market | Weeks | Weeks | 3–6 months |
| Discoverability | SEO only | SEO + app stores (via TWA/Microsoft Store) | App stores only |
If you’re choosing between them, choose depending on your needs: plain web is the best option for pure content sites, native – for hardware-heavy apps (AR, NFC, Bluetooth, etc), and PWA – for everything in-between.
How PWAs work under the hood
APIs allow the app to perform actions that were traditionally limited to native applications, enabling PWAs.
Service worker
A service worker is a JavaScript file that runs in the background, between the internet and your application. It intercepts network calls and determines whether to read data from the cache, download data from the internet, or both. Common strategies:
- Cache-first – serve from cache, fall back to network. Best for static assets
- Network-first – try network, fall back to cache. Best for frequently updated content
- Stale-while-revalidate – serve cached immediately, update cache in background
Service workers also handle background sync (queue actions offline, replay when connected) and push events (receive notifications even when the app is closed).
// Register a service worker in your main JS
if ('serviceWorker' in navigator) {
navigator.serviceWorker
.register('/sw.js')
.then(reg => console.log('SW registered', reg.scope))
.catch(err => console.error('SW failed:', err));
}Web app manifest
The Web App Manifest is a JSON file telling the browser what your app should look like when installed.
No manifest? Then you won’t get an install prompt, and there’s no nice home screen icon either. It’s pretty much required if you want people to treat your PWA like a real app.
{
"name": "My App",
"short_name": "MyApp",
"start_url": "/",
"display": "standalone",
"theme_color": "#1d4ed8",
"background_color": "#ffffff",
"icons": [
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
]
}App shell architecture
The App Shell pattern is one of the smartest tricks in PWAs. On the first visit, you cache a lightweight skeleton of your app – just the basic HTML, CSS, and JavaScript structure. Then, on return visits, the browser instantly loads that shell from cache while it quietly fetches the fresh content in the background. The result? Your app feels blazing fast, even on slow connections.
Push API + Notifications API
This combination helps you get push notifications for your users when the application is not open at all. A notification comes, the service worker is triggered, and it displays the notification. The biggest success was when Apple finally made support available on iOS 16.4 in February 2023. Now it’s implemented fully and properly in Safari for installed PWAs.
Cache Storage API + IndexedDB
These two components make your PWA work effectively offline. With Cache Storage, it is easier to cache all your static resources – HTML files, CSS stylesheets, JavaScript scripts, images, and any other type of static content. IndexedDB stores structured data – user posts, form drafts, settings, etc – anything that needs to survive without the internet. Together, they give your web app the same kind of solid data persistence as native apps have.
Background Sync API
Background Sync queues actions that failed due to connectivity loss and replays them when the connection returns – automatically, without user intervention. A form submission, a message send, a file upload – all can be reliably delivered even after the browser tab closes.
9 Key Benefits of Progressive Web Apps
Progressive Web Apps offer you the same benefits as mobile apps without hassling with stores. Here are 9 of the biggest advantages that make PWAs so popular today.
They work offline
Service Worker caching keeps the app functional in areas with poor signal, when the network drops entirely, or in other unreliable conditions. Instead of an error screen, users see cached content. For travel apps, healthcare portals, and any product serving emerging markets, this is a meaningful retention driver.
They’re SEO-discoverable
Unlike native apps, every screen in a PWA is a crawlable URL. Google indexes each page independently, which means organic search can drive traffic directly to any part of your app – not just the homepage. Native apps don’t have this. For any product where organic acquisition matters, this structural difference is one of the most underrated PWA advantages.
They’re installable
When the browser detects a proper Web App Manifest and a service worker running on HTTPS, it automatically shows an “Add to Home Screen” prompt. Once installed, the PWA gets its own icon on the home screen, launches in a full-screen window without browser chrome, and genuinely feels like a native app. People who install PWAs also tend to come back way more often compared to those who just bookmark the site.
They’re linkable and shareable
Every screen has a URL. No need for any Branch or Firebase Dynamic Links configuration – deep links to product, profiles, or content are done automatically. Send a link, and the receiver lands where intended, regardless of whether they have the application installed or not.
They are responsive by default
Modern CSS makes responsive design so much easier. With tools like Grid, Flexbox, container queries, and logical properties, you can build a single layout that adapts beautifully across phones, tablets, and desktops – no separate mobile site needed. It’s not exclusive to PWAs, but it’s pretty much a baseline requirement if you want your Progressive Web App to feel great on every device.
They’re secure
HTTPS is mandatory for PWA registration. Service workers run in a restricted scope and can’t be registered on insecure origins. The manifest controls the launch surface. These aren’t best-practice suggestions — they’re requirements enforced at the browser level.
They’re cheaper to build than native
One codebase replaces separate iOS and Android teams. There’s no App Store review cycle for every update, no Swift and Kotlin duplication, no platform-specific UI paradigms to maintain in parallel. Typical cost reduction vs. native iOS + Android is 40–60%, depending on feature requirements.
They outperform legacy web apps
The App Shell architecture, combined with smart pre-caching, is what makes PWAs feel incredibly fast. On repeat visits, the app often loads in under a second because the basic shell is already cached. These performance gains show up directly in the numbers: Pinterest saw 60% higher engagement, Trivago jumped 150% in engagement, Lancôme got a 17% boost in conversions and 15% lower bounce rate, while Twitter (X) reported 75% more tweets sent and 20% fewer bounces.
They unlock re-engagement via push notifications
Web push works on Chrome, Edge, Firefox, Safari macOS, and – since iOS 16.4 – Safari iOS for installed PWAs. The Safari iOS support was the last significant platform gap for years. It’s now closed. Installed PWAs on iPhone can receive push notifications the same way native apps do, which changes the re-engagement equation significantly for any PWA that relies on iOS users.
Real-World PWA Case Studies
In theory, many things may sound nice. Well, let’s look at real-world examples with solid numbers.
+60% core engagement · +44% ad revenue
Pinterest rebuilt its mobile web experience in React over three months after discovering that only 1% of unauthenticated mobile users converted to sign up, log in, or native app install. The PWA delivered +60% core engagement, +44% ad revenue from mobile users, and +40% time spent. The page shell dropped from 650KB to 150KB. Load time went from 23 seconds to under 5 seconds on 3G.
Twitter Lite
+75% tweets sent · –20% bounce rate
Twitter built a PWA specifically for users on slow connections and limited storage. The result: 75% more tweets sent, 20% less bounce, 65% more pages per session. The PWA shell weighs 600KB – compared to 23.5MB for the native Android app. 250,000 daily users run it from their home screen and open it four times a day on average. (web.dev)
Trivago
+150% repeat engagement · +97% hotel click-outs
Over 500,000 Trivago users added the shortcut to their home screen after the PWA launched. Repeat visitor engagement went up 150%. Hotel offer click-outs – the core conversion metric – increased 97%. The traveller use case maps perfectly to PWA strengths: users on airport WiFi or hotel networks with unreliable connectivity still get a fast, functional experience.
Starbucks
99.84% smaller than a native iOS app
The Starbucks PWA lets customers browse the full menu, customize drinks, and add items to their cart while offline. When connectivity returns, the order goes through. The PWA is 233KB versus 148MB for the native iOS app – 99.84% smaller – and doubled daily active users. For markets where device storage is a constraint, that size difference determines whether a user can access the product at all.
AliExpress
+104% conversion (new iOS users)
AliExpress targeted users who weren’t downloading the native app — browsers who arrived via search or social on iOS. The PWA delivered +104% conversion for new iOS users and +82% iOS conversion overall. This is the key use case: reaching users who won’t install a native app but will use a fast, installable web experience.
Forbes
+43% sessions · 3× scroll depth
Forbes rebuilt their editorial experience as a PWA focused on load time and ad viewability. Articles now load in 0.8 seconds. Sessions per user increased 43%, and scroll depth tripled. For a publisher where every extra second of reading time translates to an additional ad impression, the compounding effect across millions of daily page views is significant.
PWA Limitations: When NOT to Choose One
PWA advocates tend to undersell the gaps. Here’s an honest list of where PWAs still fall short:
- iOS hardware access is still partial. No Web Bluetooth, no NFC payments, no USB, no background fetch on iOS. The camera works, geolocation works, but anything deeper into the hardware layer doesn’t. Apple has been slow to implement Project Fugu APIs.
- iOS push requires installation first. Push notifications on Safari iOS (since 16.4) only work after the user has installed the PWA to their home screen. If your iOS users don’t install, they don’t get push. This is a higher-friction bar than native.
- No native app store distribution by default. You lose app store ratings, “official” trust signals, and the discovery channel that app stores provide. TWA (Trusted Web Activity) lets you publish to the Play Store, and Microsoft Store accepts PWAs directly – but the App Store does not accept PWAs, and users won’t find your PWA by searching in the App Store.
- No Apple/Google billing. In-app purchases have to go through Stripe or a similar payment processor. This is actually an advantage if you want to avoid the 15-30% store tax, but it means Apple Pay and Google Pay’s native checkout flows aren’t available in the same seamless way.
- Heavy graphics, 3D, and AR apps still need native. WebGPU is shipping (more on that below), and it brings real GPU access to the browser, but video editors, demanding games, and AR shopping experiences are still better served by native or a hybrid approach.
- Some enterprise MDM channels don’t support PWAs. Corporate device management and B2B app distribution portals often have no mechanism for deploying PWAs. If your customers are IT departments managing fleets of locked-down devices, check your target MDM platform before committing to a PWA-only approach.
Decision rule: If your app is content-, commerce-, or communication-driven – go PWA. If it’s hardware- or media-production-driven – go native or consider a hybrid approach (React Native, Flutter).
How to Build a PWA: Tech Stack & 6-Step Path
Frontend frameworks with PWA support
- Next.js – next-pwa adds Service Worker and manifest with minimal config. The most commonly used stack for PWAs in 2026.
- Nuxt – @nuxtjs/pwa module handles manifest, icons, and workbox integration.
- Angular – ng add @angular/pwa adds Service Worker support in one command.
- SvelteKit – PWA plugin available; excellent baseline performance before any optimization.
- Vite + vite-plugin-pwa – framework-agnostic, works with any Vite project.
- Remix — manual Service Worker setup; more control, more work.
Service Worker tooling
Workbox (Google) is the standard. It provides pre-built caching strategies, runtime caching, background sync, and push notification handling – saving you from writing the Service Worker lifecycle management manually.
Auditing
Lighthouse in Chrome DevTools gives you a PWA score alongside performance, accessibility, and SEO scores. It shows exactly which installability requirements you’re missing.
The 6-step path
- Serve over HTTPS. Vercel, Netlify, and Cloudflare Pages all give HTTPS by default. On your own server, use Let’s Encrypt. No HTTPS = no Service Worker = no PWA.
- Make it responsive and fast. Aim for 90+ on Lighthouse mobile performance before adding PWA features. A fast, responsive baseline is the foundation everything else builds on.
- Add a Web App Manifest. Create manifest.json with name, short_name, start_url, display: “standalone”, and icons at 192×192 and 512×512. Link it in your HTML <head>.
- Register a Service Worker. Use Workbox if you’re on Next.js, Nuxt, or Vite — it auto-generates the Service Worker from your config. Manually, if you need fine-grained caching control.
- Add Web Push. Generate VAPID keys, subscribe users via the Push API, and use a managed provider (OneSignal, Pusher Beams, or an in-app messaging SDK that handles push) to skip the server-side push relay work.
- Test installability and ship. Run Lighthouse → check the “Installable” PWA section. Fix anything flagged. Test the install prompt on Chrome Android and Safari iOS 16.4+. Deploy.
PWAs in 2026: What Changed and What’s Next
iOS web push is mature. Safari iOS 16.4 (shipped 2023) added push notifications for installed PWAs. As of 2026, the feature is stable and well-tested. This was the single biggest limitation holding PWAs back on iPhone – it’s no longer an issue for installed users.
Project Fugu closing the native gap. Project Fugu is Chromium’s ongoing API rollout: File System Access, Web Bluetooth, Web USB, WebHID, Screen Capture. The gap between PWA and native hardware capability narrows with each Chrome release.
WebGPU generally available. WebGPU landed in Chrome 113 and is now supported across major browsers. High-performance graphics and ML inference in the browser, which expands the set of apps that can viably run as PWAs.
AI-native PWAs. Chat-first interfaces, RAG-powered search, and AI assistants embedded directly in the web app are the 2026 pattern. A PWA with an AI chat layer and push notifications is a meaningfully different product from a PWA without one – and it’s now buildable without a backend team.
EU Digital Markets Act + Play Store / Microsoft Store acceptance. Service Worker and Web App Manifest support is now 98%+ across browsers. PWAs can be published to the Play Store via TWA and are accepted in the Microsoft Store natively. The App Store still doesn’t accept PWAs, but EU DMA requirements are pushing Apple toward alternative distribution channels.
Build Your Own: Add Real Engagement to Your PWA with Ethora
PWAs aren’t the “almost as good as native” compromise they were five years ago. With iOS web push mature, capability APIs catching up, and frameworks like Next.js making Service Worker setup a one-liner, the gap between PWA and native has narrowed to a handful of edge cases. For many consumer and B2B apps – content, commerce, communication, fintech, marketplaces, healthcare portals – a PWA gets you to market in weeks instead of quarters.
The remaining lever is engagement: a PWA that nobody talks to or returns to is just a faster website. If you want to add chat, AI assistants, push, and community features without writing a backend, Ethora’s chat widget for PWA drops in with a single script tag and ships in five minutes:
<!-- Drop this in your PWA's <head> or before </body> -->
<script src="https://cdn.ethora.com/widget.js"
data-app-id="your-app-id"></script>Works alongside Next.js, Nuxt, Angular, SvelteKit, or vanilla HTML. The widget includes real-time chat, an AI bots SDK, file sharing, presence indicators, typing indicators, and web push – including iOS 16.4+ for installed PWAs.
Ethora offers a powerful Chat & Docs Engine, end-to-end encryption, offline-first (fits the PWA offline model), and AI capabilities and RAG Crawler (crawls your PWA content into a knowledge base the AI queries at inference time).
You can start right now for free. Free tier includes the full chat SDK, AI Bots, web push, and self-hosted deployment.
More Articles
AI SDK
Aug 6, 2026
Ethora 26.08: AI Message Translation, Secure Attachments, and a Compliance Audit Trail
Ethora 26.08 ships real-time AI message translation, membership-gated secure attachments, immutable audit logs, and self-hosted monitoring and load-testing tools.
Chat SDK
Aug 3, 2026
Chat SDKs Compared: How to Pick One for Your Stack, Scale, and Compliance Needs
This chat SDK comparison covers nine vendors and the open-source option across the criteria that actually decide whether an SDK survives contact with a real codebase and a real compliance team.
Try Out Ethora in Action
Experience Ethora's messaging with a dedicated demo from our CEO or start building your App right now!