Progressive Web Apps (PWAs) Explained: How They Work and When to Use Them

Mr.Tarsem Singh
27 Oct, 2026
Smartphone and laptop showing the same web app installed with its own home screen icon and app window.
Progressive Web Apps (PWAs) Explained: How They Work and When to Use Them

Chances are you’ve already used a progressive web app (PWA) and never realised it. Ever tapped an “Install” button in your browser? Or added a site to your phone’s home screen and noticed it opened just like any other app? That’s a PWA. It’s really just a regular website with a couple of extra files that let it act more like an app.

In this guide, I’ll walk through what PWAs actually are, how installing them works, how they keep going offline, and how notifications fit in. I’ll also cover which browsers support them and where they still fall short. By the end, you should have a good sense of whether a PWA makes sense for you or your project.

The Short Answer

A progressive web app, or PWA, is basically a website that feels and works a lot like an app. Depending on your browser and device, it can be installed, used offline, and even send you notifications. It’s built with regular web technologies, but it can still get its own icon and open in its own window. In many cases you can install one straight from your browser, with no app store involved. Some PWAs do make it onto app stores too, though that depends on the platform and how the developer sets things up.

It's a good fit for content sites, stores, tools, dashboards and simple utilities. It's a weaker fit for apps that need deep access to your phone's hardware. Support also differs by browser, and Apple's platforms have the most quirks.

What Makes a Website a PWA?

Here’s the thing: you can’t just flip a switch and turn a website into a PWA. Most of the time it comes down to three pieces: a web app manifest, HTTPS, and a service worker. But even with those in place, it’s not the same story everywhere. Each browser and platform has its own rules for what counts as installable, and the features you end up with can vary quite a bit.

HTTPS. The site has to load over a secure connection. Service workers (more on those below) only run over HTTPS.

Start with the manifest. It’s a tiny file, nothing fancy, and all it does is tell the browser who your app is: the name, the icons, which page to open first, how it should look once someone installs it. Chrome is picky about this. It wants a name or short name, a 192px icon, a 512px icon, a start URL and a display mode it understands. Other browsers? They’ve got their own ideas, so don’t treat Chrome’s list as gospel.

Then there’s the service worker, which is where things get interesting. It’s a script that runs in the background, away from the page itself, and it sits right between your site and the network. Every request passes through it. It can grab files, stash them in a cache, and serve them back later, even when your connection is gone. MDN calls it a kind of proxy between the web app, the browser and the network. That’s the picture I’d keep in my head.

So who does what? The manifest handles the look and the identity. The service worker does the grunt work: offline support, background tasks, and push notifications too, as long as the browser has the right APIs. And HTTPS keeps the whole setup secure. Without it, service workers won’t run on a regular site. The one exception is localhost, which browsers treat as safe, so you can build and test on your own machine without sorting out a certificate first.

The "progressive" in the name means the site should work for everyone, then add extras where the browser supports them. A PWA shouldn't break in a browser that lacks some feature. It should just skip it.

How Installation Works

Installing a PWA feels different depending on your device.

On desktop (Chrome and Edge)

Chrome and Edge show an install icon in the address bar when a site qualifies. Click it and the site gets its own window. It also shows up in places like the Start menu on Windows or the Applications folder on macOS. Chrome's guidance says installed apps can also appear in app switchers and device search.

Chrome's installation criteria have included user engagement requirements, such as at least one interaction with the page and 30 seconds of viewing time. These requirements and the conditions for displaying an installation prompt can change, so developers should check the current Chrome documentation rather than assume every browser follows the same rules.

On Android

Chrome on Android can show an install banner or an "Install app" option in the menu. Google's web.dev guide mentions that Chrome can create a WebAPK, which is a real Android package made from the site. Some other browsers only create a shortcut, because they lack the servers Chrome uses to build WebAPKs.

In practice, the installed PWA gets its own icon, appears in the app switcher and opens without the browser's address bar.

On iPhone and iPad

Apple does things its own way. There is no install prompt. According to web.dev, you add the app yourself through the browser's Share menu, and the option is called "Add to Home Screen."

Apple also changed the default in iOS 26. According to the WebKit team, every site added to the Home Screen now opens as a web app by default. Before, a site only did that if it had the right manifest or meta tag. If you'd rather have a plain bookmark, you can switch off "Open as Web App" in the add dialog.

On a Mac

Safari on Mac has an "Add to Dock" feature, which WebKit introduced with Safari 17 in September 2023. Any website added this way opens as a web app.

How Offline Support Works

Offline mode is the part people get most excited about, and the part people misunderstand most.

A PWA doesn't magically work offline. The developer decides what gets saved. When you first visit, the service worker can store key files in the cache. Those usually include the page layout, styles, scripts and a fallback page. Next time you open the app with no signal, the service worker hands over those saved files instead of failing.

What this means in real life:

  • Pages you've already visited can load without a connection. This depends on how the developer set up caching.
  • Live data won't update. A weather PWA can show the last forecast it saved, but it can't fetch a new one.
  • Actions that need a server won't finish. You can't complete a purchase or send a message with no connection, unless the developer built a queue that waits for the network to return.

Developers often use different caching rules for different content. A common one is "network first": try the internet, and fall back to the saved copy if it fails. Another is "cache first," which suits files that rarely change, like fonts and logos.

A catch on Safari: stored data can be wiped

Safari's tracking-prevention rules can affect data that websites store in the browser. WebKit documents a seven-day limit on certain script-writable storage under specific tracking-prevention conditions. This can affect data such as IndexedDB and local storage, as well as service worker registrations and caches. The exact behavior depends on the applicable rules, so developers should not treat browser storage as permanent.

Apple has said this doesn't apply the same way to apps added to the Home Screen. Those have their own usage counter, which resets each time you open the app. So on iPhone, an installed PWA is safer for offline data than the same site in a normal Safari tab.

If you build a PWA, don't treat the cache as permanent storage for anything important. Keep a copy on the server.

Push Notifications

Notifications are another reason businesses like PWAs. They let a site reach you after you've closed it.

On Android and desktop Chrome or Edge, a PWA can ask permission to send push notifications, much like a native app. The service worker receives the message in the background and shows the alert.

On iPhone and iPad, web push notifications have more limitations. Apple added Web Push in iOS and iPadOS 16.4 for web apps added to the Home Screen. To use this feature, users must first add the website to the Home Screen. The permission request must also follow a direct user interaction, such as pressing a "Subscribe" button. Once permission is granted, notifications can appear on the Lock Screen and in Notification Center and can work with Focus modes. Users can manage notification permissions in Settings.

Home Screen web apps can also show a badge count on the icon, using the Badging API. Apple added that in iOS 16.4 too.

A quick tip for readers: if a site's notifications don't work on your iPhone, check that you opened it from the Home Screen icon and not from Safari.

Browser Compatibility at a Glance

Whether a PWA works for you depends a lot on where you open it. Support isn’t the same across browsers and operating systems. Chrome and Edge both have installation built right in, while Apple devices do it their own way. Firefox is a bit more patchy, since it handles some PWA features and skips others. So before you build anything around one specific feature, check the browser’s current documentation. Here’s a quick summary.

Browser / platform Installing Notes
Chrome and Edge (desktop) Yes, with an address bar install button Support the beforeinstallprompt event, so a site can show its own install button
Chrome (Android) Yes Can create a WebAPK
Safari (iPhone, iPad) Manual, through Share > Add to Home Screen No install prompt. Push works only for Home Screen web apps
Safari (Mac) Add to Dock Available since Safari 17
Firefox (desktop) Limited and experimental Mozilla's "Taskbar Tabs" is not full PWA support

A few details are worth knowing. The beforeinstallprompt event, which lets a site show a custom install button, is listed as supported in Chrome 76 and later and Edge 79 and later, but not in Firefox or Safari. So an "Install our app" button you see on one browser may not appear on another.

Firefox on desktop is where things get awkward. It doesn’t give you the same built-in install experience that Chrome and Edge do, so you can’t count on a neat little install button. And that’s only one example, because support for individual web app features changes from browser to browser. If you’re building something, check Mozilla’s current documentation and actually test your site in the Firefox version you plan to support. Google’s own PWA checklist makes a similar point: some features won’t work everywhere, so build a fallback. It’s good advice. Don’t let a core feature depend on something only one browser can do.

The Limitations You Should Know About

PWAs are useful, but they aren't a perfect replacement for native apps.

Uneven support. As the table shows, the same PWA can behave differently on Chrome, Safari and Firefox. Testing on each platform matters.

Weaker discovery. Many people still search an app store first. A PWA doesn't show up there by default. There are routes around this. Web.dev notes that you can list a PWA in Google Play or the Microsoft Store using tools like Bubblewrap and PWABuilder. But the listing process differs by store, and it takes extra work.

Limited device access. A native app often has deeper access to hardware and system features. A PWA only gets what the browser exposes, and that varies by browser. If your idea depends on advanced hardware access, check support before you commit.

Offline isn't automatic. It has to be planned and tested. A badly cached app can show old content, or fail in odd ways when the connection drops.

Storage can be cleared. As covered above, Safari can remove stored data from sites you haven't used in a while. Other browsers can also clear cached data when a device runs low on space.

Installing is less obvious to users. Plenty of people don't know a site can be installed. On iPhone, they have to find the Share menu on their own.

When a PWA Makes Sense

PWAs work best when you want reach, low cost and easy updates more than deep device features.

Good fits:

  • News, blog and content sites that want a home screen icon and faster repeat visits
  • Online stores that want a lighter alternative to a full mobile app
  • Tools and dashboards, such as note-taking, task lists and internal business apps
  • Small businesses that can't afford separate iOS and Android apps
  • Sites with readers on slow or unreliable connections

One big plus is that a PWA is one codebase. Google's own guidance points out that you can keep one app for everyone, which saves time and cost. Updates also go out the same way as a normal website update, with no app store review for each change.

Poor fits:

  • Games or creative tools that need heavy graphics or special hardware access
  • Apps that depend on features only some browsers offer
  • Products where app store visibility is the main way people find you
  • Anything where users must be reachable by push notifications, and many of those users are on iPhone but unlikely to add it to the Home Screen

A middle path is common. Many teams build the PWA first, see how people use it, and add a native app later if they need one.

A Quick Checklist for Site Owners

If you're thinking about turning your site into a PWA, start here:

  1. Make sure the whole site runs over HTTPS.
  2. Write a manifest with a name, a start URL, a display mode and icons in the required sizes.
  3. Register a service worker and decide what really needs to work offline.
  4. Add a simple offline page, so people see something helpful and not a browser error.
  5. Test installing on Chrome, Edge, Safari on iPhone, and at least one Android phone.
  6. Ask for notification permission only after a user action, and only if you'll send useful messages.
  7. Keep important data on your server, not only in the cache.

Chrome's built-in developer tools can check your manifest and service worker, which helps you catch problems early.

Final Takeaway

A PWA can give a website app-like features, including installation, offline use and notifications where supported. A manifest, service worker and HTTPS are common parts of this setup, although exact requirements vary by browser and platform.

Just don't expect identical results everywhere. Chrome and Edge provide built-in installation options, while Apple platforms use a different installation process and limit web push notifications to supported Home Screen web apps. Firefox also differs in its support for individual PWA features.

If your goal is wide reach and simple upkeep, a PWA is worth a serious look. If you need deep hardware access or a strong app store presence, compare the available PWA features with those of a native app before deciding.

Sources

Disclaimer: Browser features and Apple's iOS rules change often. Check the official documentation for current details before you build or publish a PWA.

Written by Mr. Tarsem Singh
Founder & Editor, Beinfora
This article was researched and written by Mr. Tarsem Singh to provide clear, useful technology information for readers

Next Post Previous Post
No Comment
Add Comment
comment url