Which Browsers Don't Support PWAs Properly Yet?

There's nothing quite as frustrating as building a progressive web app, testing it on your development machine where everything works perfectly, and then having a client tell you it doesnt work properly on their iPhone. I mean, you've followed all the best practices, written clean code, and tested the major features—but here's the thing: not all browsers treat PWAs the same way. Some browsers fully embrace what PWAs can do, whilst others seem determined to make your life difficult by implementing half the features or ignoring them completely.

Progressive web apps have been around long enough now that you'd think browser support would be sorted. But it's not. Different browsers have different priorities, different ideas about what users need, and honestly, different motivations when it comes to supporting web technologies that might compete with their native app ecosystems. Safari, for instance, has been notoriously slow to adopt certain PWA features—and we'll get into why that matters in a bit. Firefox takes its own unique approach to how users install PWAs. And dont even get me started on Internet Explorer.

The reality is that building a PWA means accepting that your app will behave differently depending on where people access it, and planning for those differences from the start rather than discovering them after launch

Understanding which browsers support PWAs properly (and which ones dont) isn't just technical knowledge for the sake of it; it directly affects your development decisions, your testing strategy, and ultimately whether your app delivers a good experience to actual users. If you're planning to build a PWA or you've already started, knowing the limitations across different browsers will save you time, money, and quite a few headaches down the road.

What PWAs Actually Are and Why Browser Support Matters

Right, so let's start with the basics because there's a lot of confusion about what PWAs actually are. Progressive Web Apps—or PWAs as everyone calls them—are basically websites that behave like native mobile apps. They can work offline, send you push notifications, and sit on your home screen right next to your other apps. The clever bit? They're built using standard web technologies like HTML, CSS and JavaScript, which means you don't need separate codebases for iOS and Android.

I've built dozens of these over the years and the appeal is obvious; you write your code once and it works everywhere. Well, thats the theory anyway. The reality is a bit more complicated because not all browsers support PWAs in the same way, and some don't really support them properly at all.

Here's the thing—PWAs rely on specific browser features to work their magic. They need service workers (which handle offline functionality), web app manifests (which tell the browser how the app should look when installed), and various APIs for things like notifications, background sync, and camera access. If a browser doesn't support these features or implements them poorly, your PWA wont work as intended.

Key Technologies That Make PWAs Work

• Service Workers for offline caching and background processes
• Web App Manifest for installation and display settings
• HTTPS requirement for security (non-negotiable really)
• Push Notification API for user engagement
• Background Sync for delayed data transmission
• Various device APIs like camera, geolocation and sensors

Browser support matters because if your target audience is using a browser that doesn't properly support PWAs, they wont get the full experience you've built. And unlike native apps where you can just say "download from the App Store", with PWAs you're at the mercy of whatever browser your users happen to prefer. Its a bit frustrating honestly, but understanding these limitations helps you make better decisions about whether a PWA is right for your project.

Safari's Long-Standing Issues with PWA Features

Right, let's talk about Safari—because honestly, if you're building a PWA, Safari is probably going to give you more headaches than any other browser. I've lost count of how many times clients have come to me confused about why their PWA works perfectly on Android but acts completely differently on iOS. The answer? Safari's approach to PWAs has been, let's say, selective at best.

Apple has supported basic PWA functionality since iOS 11.3, but here's the thing—they've implemented it in their own way, which means leaving out features that other browsers consider standard. It's a bit frustrating really, because Safari has such a massive market share (especially in certain regions) that you cant just ignore it. You need to build around its limitations.

The biggest issue I see with Safari is how it handles installed PWAs. When someone adds your PWA to their home screen on iOS, Safari treats it differently than other browsers do. Push notifications? Only recently added and still limited. Background sync? Nope. Bluetooth access? Forget about it. And don't even get me started on how Safari clears service worker caches if the user doesn't open your PWA for a few weeks—it basically treats your installed app as if it was never used.

What Safari Doesn't Support Properly

Here are the main PWA features that Safari either doesn't support or implements poorly:

• Web Push Notifications (only very recently added with heavy restrictions)
• Background Sync for offline data synchronisation
• Periodic Background Sync
• Bluetooth Web API
• File System Access API
• Web NFC
• Contact Picker API
• Install prompts (users must manually add to home screen)

Always test your PWA on actual iOS devices, not just Safari on Mac. The mobile version behaves very differently and has more restrictions than desktop Safari—trust me on this one.

The storage limitations are another problem. Safari aggressively purges cached data, sometimes after just 7 days of inactivity. This means your PWA might lose all its offline content without warning, which defeats half the purpose of building a PWA in the first place. I've had to explain to clients that their beautifully designed offline-first app will need constant internet connectivity on iOS because Safari just wont play nice with persistent storage.

Firefox and Its Approach to PWA Installation

Firefox has always been a bit of an odd one when it comes to PWAs. On desktop, they supported the basic tech behind PWAs for ages—service workers, web app manifests, all that good stuff—but they deliberately chose not to add an install prompt or any way to actually install PWAs like proper apps. I mean, the functionality was there under the hood, but users had no way to access it without jumping through hoops.

Here's the thing; Firefox's reasoning was actually pretty sound from a philosophical standpoint. They were concerned about blurring the lines between websites and native apps, worried about security implications, and honestly just weren't convinced users needed another type of "app" cluttering their systems. Fair enough. But it left developers in a tricky spot because you'd build a PWA that worked beautifully in Chrome, only to have Firefox users completely miss out on the installed experience.

On Android, Firefox does support PWA installation to some degree—users can add PWAs to their home screen and they'll run in a standalone window. Its not as polished as Chromes implementation but it works. The desktop version is where things get messy. For the longest time there was no installation option at all, then they added experimental flags that most users would never find or enable.

What really matters for your PWA is understanding that a decent chunk of Firefox users wont be able to install your app the traditional way. They can still use it as a website obviously, and all your offline functionality through service workers will work fine. But that native app feel? That's going to be missing for them unless they're on Android and know what theyre doing.

Internet Explorer and Older Edge Versions

Right, let's talk about Internet Explorer and the original Edge browser—what Microsoft called EdgeHTML before they switched to Chromium. If you're building a PWA and need to support these browsers, I'm going to be honest with you: you're in for a rough time. Internet Explorer never supported PWAs at all. Not even a little bit. It was built before PWAs were really a thing, and Microsoft stopped developing it years ago, so there's zero PWA support and there never will be.

The original Edge browser (the one that came with Windows 10 before Microsoft rebuilt it on Chromium) had some PWA support, but it was patchy at best. Sure, it could handle service workers and manifest files, but the implementation was incomplete and buggy. Push notifications didn't work properly, background sync was missing entirely, and the installation experience was clunky compared to what you'd get in Chrome or even Safari. I've seen apps that worked perfectly in Chrome completely fall apart in EdgeHTML—it's a bit frustrating really, especially when you've spent weeks getting everything just right.

The good news is that almost nobody uses these browsers anymore, with Internet Explorer usage now sitting well below 1% globally and the old Edge having been replaced entirely by the new Chromium-based version.

Here's the thing though—you might still encounter clients or users who need to support legacy systems, particularly in corporate environments where IT departments move slowly. In those cases, your best bet is to provide a fallback experience; basically a regular website that works without PWA features. Don't try to force PWA functionality on browsers that cant handle it properly. Test what breaks, provide graceful degradation, and make sure your core functionality still works even if the fancy PWA bits don't. Its not ideal, but sometimes that's just the reality of web development.

Chrome and Chromium Browsers Leading the Pack

Right, let's talk about the good news for once—because honestly, after dealing with Safari's limitations and Firefox's half-hearted approach, it's refreshing to discuss browsers that actually get PWAs. Chrome has been the driving force behind Progressive Web Apps since Google introduced the concept, and it shows. I mean, Chrome on Android supports basically every PWA feature you can think of: installation to the home screen, push notifications, background sync, offline functionality, the works. It's the standard I measure everything else against when testing PWAs for clients.

But here's the thing—its not just Chrome itself. Because Chrome is built on the open-source Chromium engine, a whole family of browsers get the same excellent PWA support. Microsoft Edge (the new version, not the old one we talked about earlier), Brave, Opera, Samsung Internet, and even smaller browsers like Vivaldi all inherit Chromiums PWA capabilities. This means that collectively, Chromium-based browsers account for something like 70% of global browser usage, which is brilliant news if you're building a PWA.

The install process on Chrome is smooth too. Users get a clean prompt asking if they want to add the app to their device, and once installed, the PWA behaves like a native app—full screen, with its own icon, appearing in the app drawer alongside regular apps. No weird browser UI getting in the way.

What Chrome Does Right

Chrome's implementation covers all the technical bits properly:

• Full support for service workers and caching strategies
• Push notifications that actually work reliably (on Android at least)
• Background sync for offline data handling
• Web App Manifest support with all the bells and whistles
• Payment Request API for simplified checkout flows
• Geolocation and other device APIs work without issues

Google has a vested interest in making PWAs succeed, which means Chrome keeps getting better PWA support with each update. They're actively working on new capabilities and actually listen to developer feedback, which you can't say for every browser maker out there.

Mobile Browser Differences Between Android and iOS

Right, let's talk about the elephant in the room—Android and iOS handle PWAs completely differently and its pretty frustrating if I'm being honest. After building apps for both platforms for years, I can tell you the mobile browser situation is a proper mess when it comes to PWA support. Android users get the full experience while iOS users... well, they get what Apple decides to give them.

On Android, Chrome is the dominant browser and it supports PWAs brilliantly. Users can install PWAs directly from Chrome, they get a proper app icon on their home screen, and the PWA can do almost everything a native app can do—push notifications work, background sync works, and the experience feels genuinely app-like. Samsung Internet (which more people use than you'd think) also has solid PWA support. The Android ecosystem basically treats PWAs as first-class citizens.

But here's the thing—iOS is a different story entirely. Safari is the only browser that really matters on iOS because Apple forces all other browsers to use Safari's WebKit engine under the hood. So when you install Chrome or Firefox on your iPhone? You're actually just using Safari with a different interface. This means Safari's limitations become everyone's limitations on iOS, and Apple has been painfully slow to add PWA features. Push notifications only arrived recently on iOS, and even then they're limited. Background sync? Forget about it. The install experience is hidden behind the share button rather than being prominent like on Android.

Key Differences at a Glance

• Android Chrome supports push notifications, background sync, and offline functionality fully
• iOS Safari limits PWA capabilities and hides the install option in the share menu
• Android gives PWAs access to more device APIs and hardware features
• iOS restricts PWA storage and can clear data if the app isnt used regularly
• Android lets users set PWAs as default apps for certain actions; iOS doesn't

Always test your PWA on an actual iPhone, not just in Safari on a Mac. The mobile version has different limitations and bugs that won't show up in desktop testing—trust me on this one!

The storage situation is particularly annoying. iOS can clear a PWA's data if it hasnt been used for a while, which means users might lose their local app data. Android treats PWA storage more like native app storage and doesn't randomly wipe it. This affects how you build your data persistence strategy... you basically need to plan for iOS potentially losing everything.

The Features Most Commonly Missing or Broken

After years of building PWAs for clients, I've learned to expect certain features to be either completely missing or only half-working depending on which browser someone's using. It's a bit frustrating really, because these are often the exact features that make PWAs feel like proper native apps rather than just glorified websites. The good news? If you know what to watch out for, you can plan around these limitations from the start—or at least warn your users when something won't work as expected.

Push notifications are probably the biggest headache. They work beautifully on Chrome and Firefox for desktop, and on Android devices generally, but Safari on iOS? Not a chance. Apple simply doesn't allow web-based push notifications on iOS, which means if that's a core feature of your PWA you need to have a backup plan. I've seen developers spend weeks building notification systems only to realise their iPhone users can't receive them at all.

Background sync is another feature thats hit or miss

This is what lets your PWA save data when someone's offline and then sync it automatically once they're back online. Chrome supports it well, but Safari doesn't support it properly yet and Firefox only has partial support. If your app needs to work offline reliably—which is kind of the whole point of a PWA—you'll need to build alternative solutions for browsers that don't handle background sync.

Other commonly broken or missing features

Here's what else tends to cause problems across different browsers:

• Install prompts and add-to-home-screen functionality (Safari makes this particularly awkward for users)
• Bluetooth connectivity for connecting to external devices
• Access to device contacts or calendar
• Geolocation fencing and background location tracking
• File system access for reading and writing files locally
• Payment request API integration
• Badge notifications on app icons

The reality is that PWAs still can't do everything native apps can do, and the gap gets even wider when you look at browser support. I always tell clients to prioritise the features that actually work across all major browsers rather than building something that only works perfectly in Chrome. You know what? Sometimes the best solution is accepting that certain advanced features simply aren't worth implementing if half your users won't be able to access them anyway.

How to Test Your PWA Across Different Browsers

Right, so you've built your PWA and now you need to make sure it actually works everywhere. Testing across browsers is honestly one of the most important steps—and its something I see people rush through all the time. Big mistake. You can't just check it works in Chrome and call it a day.

The first thing I do is set up a proper testing environment with real devices, not just browser emulators. Sure, Chrome DevTools has a mobile simulator and its useful for quick checks, but nothing beats testing on an actual iPhone or Android phone; the behaviour can be completely different. I keep a collection of devices in the studio for exactly this reason—different iOS versions, various Android manufacturers, even some older models because not everyone upgrades their phone every year.

What to Actually Test

Start with the installation process itself. Try adding your PWA to the home screen on each browser and see what happens. Does the install prompt appear? Does the icon look right? When you launch it, does it open in standalone mode or does it just open a browser tab? These basics trip people up constantly.

Next, test offline functionality. Turn off your wifi (or use airplane mode) and see if your service worker is doing its job. Can users still access cached content? Do they get a helpful offline message? Safari on iOS is particularly tricky here because it limits service worker cache size and can purge it without warning.

The difference between what works in your local development environment and what works on a users actual device in the wild can be massive

Don't forget push notifications—test whether they work at all (they wont on iOS Safari), and check if background sync functions as expected. I use tools like BrowserStack or LambdaTest for testing across multiple browser versions quickly, but nothing replaces manual testing on real hardware for the final check before launch.

Look—PWA support across browsers is still a proper mess, lets be honest about that. Safari's holding things back with its limited functionality, Firefox has made some progress but still doesn't quite get it right, and anything older than the new Chromium Edge is basically useless for PWA work. Chrome and its Chromium cousins are leading the way, sure, but even then you'll find inconsistencies between what works on Android versus iOS.

The thing is, this isn't going to stay the same forever. Browser vendors are constantly updating their support (or in Safari's case, dragging their feet whilst occasionally adding features when the pressure gets too much). What doesn't work today might work in six months; what works perfectly now might break in the next update. Its just the nature of web development really.

So where does that leave you? Well, you need to test your PWA across every browser your users actually use—not just the ones you prefer developing on. Build for the best experience on Chrome and Chromium browsers where PWA support is strongest, but make sure your app still functions as a regular website on browsers with poor PWA support. Think progressive enhancement, not "Chrome only".

And honestly? Keep an eye on browser release notes and support tables because things change fast in this space. The PWA landscape is still maturing, and whilst we'd all love universal support across every browser, we're just not there yet. Maybe we will be eventually...but until then, its our job to build apps that work for real users on real devices, regardless of which browser they happen to be using. Test everything, assume nothing, and always have a fallback plan for when PWA features aren't available.