What Is a Progressive Web App? (2026 Guide)

A progressive web app is a website that can be installed on a phone or desktop, opened from its own icon, and still work when the network drops. That’s the whole idea. Everything else (manifests, service workers, install prompts) exists to make those three things possible.

I’ve built both PWAs and native apps for clients around Long Island, and the honest answer to “should I build a PWA?” depends almost entirely on two questions: do you need reliable push notifications, and do you need to be in the App Store? Get those right and the rest is mostly plumbing.

What a PWA actually is

Strip away the marketing and a PWA is a normal website served over HTTPS that adds two files and a bit of JavaScript. Those additions let the browser treat it like an app: install it to the home screen, cache assets for offline use, and run some code in the background. There’s no separate codebase, no separate build pipeline, no separate deployment. You ship one thing and it works in a browser tab and as an installed app.

The confusing part is that “PWA” describes a spectrum, not a checkbox. A site with a manifest and nothing else technically installs, but it’s just a bookmark with an icon. A site with a well-built service worker, offline fallbacks, background sync, and push is genuinely app-like. Most of the value lives in that second category.

The three pieces that matter

1. HTTPS

Service workers only run on secure origins. That’s a hard requirement, no exceptions for localhost during development aside. If you’re not on HTTPS in 2026, you have bigger problems than PWAs, since browsers flag plain HTTP as “Not Secure” in the address bar.

2. The web app manifest

A JSON file that tells the browser how to present your app when installed: name, icons, colors, display mode, start URL. This is what makes the installed icon look like a real app instead of a shortcut.

{
 "name": "Key Field Tools",
 "short_name": "Field Tools",
 "start_url": "/app/",
 "scope": "/app/",
 "display": "standalone",
 "background_color": "#ffffff",
 "theme_color": "#0b5fff",
 "icons": [
 { "src": "https://i0.wp.com/www.kennykey.com/icons/192.png", "sizes": "192x192", "type": "image/png" },
 { "src": "https://i0.wp.com/www.kennykey.com/icons/512.png", "sizes": "512x512", "type": "image/png" },
 { "src": "https://i0.wp.com/www.kennykey.com/icons/maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
 ]
}

Two details people get wrong. First, scope controls which URLs count as “inside” the app. Set it wrong and links kick users out to a browser tab. Second, you need a maskable icon or Android will shrink your logo into a sad little circle with padding around it.

3. The service worker

A service worker is a JavaScript file that sits between your page and the network. It can intercept every request and decide what to do: serve from cache, hit the network, or fall back to something else. This is the piece that delivers offline support.

const CACHE = 'app-v3';
const ASSETS = ['/', '/app/', '/styles.css', '/app.js', '/offline.html'];

self.addEventListener('install', (event) => {
 event.waitUntil(
 caches.open(CACHE).then((cache) => cache.addAll(ASSETS))
 );
 self.skipWaiting();
});

self.addEventListener('activate', (event) => {
 event.waitUntil(
 caches.keys().then((keys) =>
 Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k)))
 )
 );
 self.clients.claim();
});

self.addEventListener('fetch', (event) => {
 const { request } = event;
 if (request.method !== 'GET') return;

 // Network-first for API calls, cache-first for static assets
 if (request.url.includes('/api/')) {
 event.respondWith(
 fetch(request).catch(() => caches.match(request))
 );
 return;
 }

 event.respondWith(
 caches.match(request).then((cached) => cached || fetch(request))
 );
});

That’s a reasonable starting point, not a finished product. Real apps need cache versioning discipline (bump CACHE on every deploy or users get stale files forever), a strategy per request type, and a plan for what happens when a user is offline and tries to do something that requires the server. Getting the caching strategy wrong is the number one way PWAs break in production.

What PWAs are genuinely good at

• Cost. One codebase instead of iOS, Android, and web. For a small business that needs an app-like experience for customers, this is often the entire argument. You’re not paying for three teams or three release cycles.
• Instant updates. Deploy to your server and every user has the new version on next load. No app store review, no “please update” nag screens, no users stuck on a two-year-old build.
• No app store gatekeeping. No 15 to 30 percent cut, no rejection roulette, no waiting a week for a bug fix review. You control distribution completely.
• Discoverability. It’s a website. It gets indexed, it gets linked, it works from an email or a text message. A native app needs a store listing and an install funnel before anyone can use it.
• Small footprint. A well-built PWA can be a few hundred kilobytes of cached assets. A native app with dependencies is often 50 to 150MB. On lower-end Android devices with limited storage, that difference decides whether someone installs at all.

The honest limitations

This is where most PWA articles get dishonest, so let me be specific.

iOS is still behind, even in 2026

Apple has improved things. Web push works on iOS for installed PWAs (added in iOS 16.4), and install support via Safari’s Share menu has gotten smoother. But the gap hasn’t closed:

• Push requires installation first. On Android, a user can grant notification permission from the browser. On iOS, push only works if the user has already added the PWA to their home screen. That’s a big funnel drop, and there’s no way around it.
• No install prompt. Android Chrome shows a native “Add to Home Screen” banner when your app meets the criteria. iOS shows nothing. You have to teach users to tap Share, then “Add to Home Screen.” Many won’t.
• Background execution is limited. Background sync, periodic background fetch, and long-running tasks are unreliable or missing. If your app needs to sync data while closed, iOS will fight you.
• Storage can be evicted. Safari may clear cached data for sites that haven’t been used in a while. Your offline experience can quietly disappear for a returning user.
• No access to many device APIs. Bluetooth, NFC, advanced camera controls, and most hardware integrations are either unavailable or heavily restricted.

Performance ceiling

A well-optimized PWA feels fast. A poorly-optimized one feels like a website, because it is one. Heavy animation, complex gestures, and 60fps scrolling on low-end hardware are harder to guarantee than in native code. You can get close with modern frameworks, but “close” is the operative word.

Store presence matters to some users

For consumer apps, being in the App Store is a trust signal. People search the store, they don’t search the web, and “install this website” is a harder sell than “download our app.” For B2B and internal tools, nobody cares. Know which side you’re on.

PWA vs native vs React Native

Here’s how I actually decide with a client.

Choose a PWA when: your product is content-heavy or form-heavy, users are mostly on Android or desktop, you need to ship fast and cheap, offline reading matters more than offline writing, and you don’t need deep hardware access. Internal dashboards, booking tools, field data collection with occasional sync, e-commerce, news, and marketing-adjacent apps all fit here. This is also the cheapest path if you already have a web app and want to make it installable.

Choose React Native (or Expo) when: you need real App Store and Play Store presence, reliable push on both platforms, and near-native UI with one codebase. If your users expect to find you in the store, or if push notifications are core to the product, this is usually the right call. You’re paying more than a PWA but less than fully separate native apps.

Choose fully native (Swift and Kotlin) when: you need camera pipelines, Bluetooth, AR, background location, heavy offline processing, or platform-specific integrations that cross-platform frameworks handle poorly. Also when performance is the product, like games or real-time media tools. This is the most expensive option and the one people over-choose.

If you already have a web app and you’re weighing the jump to native, that’s a real conversation about scope and budget, not just technology. I do a fair amount of Long Island app development and the most common outcome is a PWA first to validate the idea, then native or React Native once the product proves itself. Building three apps for an unvalidated product is how budgets die.

If you’re starting from nothing, the reverse also works. Build the native app, then ship a PWA as a lightweight companion for sharing links and quick access. Same backend, two front doors.

A note on “just wrap it in Capacitor”

Capacitor and similar tools let you wrap a web app in a native shell and ship it to the stores. That’s a legitimate middle path and I’ve used it. But be clear about what you get: you get store presence and native plugin access, and you inherit the web view’s performance characteristics. It’s not a free upgrade to native. It’s a web app wearing a native coat, and it’s the right answer more often than purists admit.

Whatever route you take, the backend and the web layer are the same work. Good custom web development is the foundation under all three options, and it’s usually where the actual product value lives.

The bottom line

A PWA is the cheapest way to give users an installable, offline-capable app, and in 2026 it’s genuinely good enough for a large category of products. It is not a native app and won’t be. If push notifications on iOS or store presence are central to your business, budget for React Native or native. If they’re nice-to-haves, ship the PWA, learn what users actually do, and spend the native budget only after you have evidence you need it.

FAQ

Do PWAs work on iPhone?

Yes, with caveats. Safari supports installation via Share, then “Add to Home Screen,” and web push works for installed PWAs since iOS 16.4. What you don’t get is an automatic install prompt, reliable background sync, or guaranteed persistent storage. Android remains a smoother experience across the board.

Can a PWA go in the App Store?

Not as a PWA. Apple’s guidelines require apps to be built with native frameworks or wrapped in something like Capacitor, and they’ve rejected thin web wrappers in the past. If store presence is a requirement, plan for a native or React Native build from the start rather than expecting to submit your PWA.

Is a PWA cheaper than a native app?

Usually, yes, often by a wide margin, because it’s one codebase instead of two or three and there’s no store review cycle. The savings shrink if you need heavy offline logic, complex animations, or deep device integration, since you’ll spend the difference fighting browser limitations. Price it honestly against your actual feature list, not the average case.