"Security and privacy" is kind of a funny one to rate. As I understand it, one of the main reasons why Safari doesn't support as many advanced APIs as other browsers is that they want to avoid technologies that pose a fingerprinting risk. From that point of view, Chrome is pretty bad.
> The fact that iOS safari supports SO many lifecycle features except BeforeInstallPrompt is just so frustrating.
BeforeInstallPrompt is non-standard. They removed it from the specification because Mozilla had no plans to support it and Apple wouldn’t commit either.
Here’s the discussion:
> There is also some disagreement on the a `BeforeInstallPrompt()` event (BIP). Despite BIP having been in the spec for a few years, neither Safari nor Firefox have opted to support it. As it stands, Mozilla does not plan to support BIP. We are unsure what WebKit's plans are - @hober maybe could let us know? If WebKit doesn't plan to support it, then we should probably remove it from the spec.
So yet again, this is a case of Google wanting something, Google implementing it unilaterally, Google not being able to convince any other rendering engine to implement it, then the non-standard, Blink-only behaviour is being presented in situations like this as if Safari alone is failing to support a standard.
Web standards are not whatever Google wants. They are arrived at through consensus.
You're absolutely right about BeforeInstallPrompt. It never achieved consensus, Mozilla declined to implement it, and this is exactly how standards should work.
But here's the thing, this actually makes the broader argument stronger, not weaker. The issue isn't any one feature rejection, it's the pattern.
Remember the iOS 17.4 thing from February 2024. Apple completely disabled PWAs in the EU, claiming alternative browser engines created insurmountable security problems that would require building "an entirely new integration architecture" that wasn't practical given DMA timelines. Then after two weeks of backlash they reversed it. If the technical barriers were real, how did they solve them in 14 days? That looks less like a technical limitation and more like testing how much they could get away with.
Or push notifications, Safari on macOS got them in 2013. Safari on iOS got them in 2023. Same WebKit engine, same APNs infrastructure, 10 years apart. What's the technical explanation for that gap?
And even after iOS finally got push notifications, they only work for PWAs installed to home screen, not in Safari itself. That's a restriction that doesn't exist anywhere else. Android Chrome has had this working in the browser since 2015.
That's the genius of plausible deniability, every individual decision has some technical justification you can point to. BeforeInstallPrompt lacks consensus (true). Safari has limited resources (as has Chrome). Security is hard (definitely true). But the cumulative effect of all these decisions, year after year, is that PWAs on iOS are hobbled compared to native apps in ways that just happen to protect a $20B+ App Store business.
Your fact-check on BeforeInstallPrompt actually demonstrates why the other patterns are harder to explain away. It shows Apple can legitimately decline features through proper standards processes, which makes the decade-long notification delay and the iOS 17.4 reversal look even more suspicious by comparison.
> The issue isn't any one feature rejection, it's the pattern.
Yes, and this pattern keeps popping up:
- Google wants something
- Google writes a spec.
- Google implements it.
- No other rendering engine wants it.
- It starts popping up on sites like this.
- People complain that it’s Apple’s fault for not implementing the standard.
Google keeps doing this over and over again. This is embrace and extend all over again. Web standards are not whatever Google wants them to be. They need to be arrived at through consensus.
Google gives Mozilla billions and billions of dollars and they still can’t get Mozilla to agree to these things. Google can’t get anybody outside of Google to implement these things.
Stop ignoring the fact that Mozilla is also saying no to a tonne of stuff. Stop ignoring the fact that no other rendering engine wants these things.
This is not “Apple is holding things back”. This is “Google is trying to unilaterally control web standards”.
You're making a fair point about Google and embrace-and-extend, but you didn't actually address the evidence I raised. Let me ask more directly.
Again, the iOS 17.4 situation. Apple claimed building PWA support for alternative browser engines wasn't "practical to undertake" due to security architecture requirements. They removed the feature. Two weeks later they brought it back. I'm asking one more time, what changed in those 14 days? If the architecture work genuinely "created insurmountable security problems that would require building "an entirely new integration architecture" that wasn't practical given DMA timelines", how was it completed so quickly?
Push notifications on iOS versus macOS. 2013 on Mac, 2023 on iPhone, same WebKit engine, same APNs backend. Apple controls the browser and the notification system on both platforms. Why the 10 year gap for what should be the same technical implementation?
The thing is, whether or not Google tries to control standards doesn't explain these Apple-specific patterns that are clearly driven by Apple's conflict of interest. Mozilla declining BeforeInstallPrompt doesn't explain why features Apple already built for macOS took a decade to reach iOS. These are implementation decisions about Apple's own technology on Apple's own platforms.
You can argue Google is problematic (I'd also agree on that!) and also admit that Apple's decisions around PWAs are clearly driven by their conflict of interest to protect their $20+ billion dollar App Store business model. Those aren't mutually exclusive. But you haven't explained the iOS 17.4 reversal or the notification delay at all. Could you address those specifically?
Should we really care what the rendering engines want? What about what users and app authors want? If Google was adding things that nobody cared about, it wouldn't be a problem. The problem is that these things are useful.
>Seems doubtful to me. Native apps just tend to feel better.
That may have being true a few years ago, but now days unless you are really pushing for very specific stuff GPU stuff. With CSS GPU acceleration its barely noticeable for normal UIs. Now there are tons and tons of PWA that is done in a very in efficient way, then you get a really laggy app.
If the theory is that if you do everything perfectly, you can reach the performance of a mediocre native app, then obviously most PWAs are going to suck and opinions will form accordingly.
You don't have to do everything perfectly. Both web apps and "native" apps will be similarly affected by a dev who is terrible at coding. Most people use web apps every day and are not even aware that they are using web apps. Some special interest groups are just very persistent in perpetuating falsehoods and myths in this matter.
>Seems doubtful to me. Native apps just tend to feel better.
I'm really tired of hearing this quite frankly, because the reasons as to why that happens to be the case in some scenarios is not "just" a coincidence, which has been explained ad nauseam.
>This scorecard says that Chrome for Android already does pretty well, but how many users use PWAs on Android?
While I've not seen any stats, I personally use them where possible. Interestingly, my boomer Dad, who is completely clueless when it comes to technology, independently discovered them. He has no idea what a "PWA" is, but he always asks me to "make this website an app for me".
That would be the interesting thing for an EU regulation to try to cover, maybe more than the app store regs. PWAs are just websites, so Apple can't really make same security argument, right?
I'm still so pissed at how Apple continues to hamstring PWAs to push their own platform. Can't wait for the day their app store era is over and something actually user-focused is prevalent
They’re pretty poor-to-mediocre under Android too. iOS isn’t helping but PWAs themselves also need to become much better to have any chance of displacing native apps.
I can easily imagine a world where you could install an open source PWA from an archive file into its own security sandbox without any further hoops to jump through, and it continues to just work indefinitely because the web has very good backwards compatibility guarantees. Instead, we have to get licensed and notarized by the monopolies and they keep you on a constant treadmill of drudgery just to stay up to date. Or you install somebody else's monopoly-approved "legitimate business" app which steals or leaks your data. Sad!
> the web has very good backwards compatibility guarantees
Kinda... Google and folks have been cracking down on security pretty hard, to the point where certain things would probably stop working if you weren't maintaining the security of the endpoint or something correctly. There are APIs (more and more everyday it seems...) that only work with "secure contexts" like HTTPS, and they're working actively on tightening HTTPS requirements (like shortening certificate lifetimes, valid ciphers etc). Sure, this helps improve security, but not without breaking compatibility.
I like the idea of actually testing for the capabilities. Can you share more about what you'd find useful? Maybe a "benchmark my browser" feature that adds a column?
The data sources are credited at the bottom, and I feel like they're both gold-standard references. I'm open to suggestions!
Remove all the non-standard stuff. If only Blink supports something because no other rendering engine thinks it should be implemented, then it doesn’t belong here. It’s non-standard, vendor-specific behaviour that you’re making people think is standard.
I can create a filter for that, thanks for the feedback! Importantly, experimental and non-standard features are not counted in the primary score.
Experimental capabilities have a little 'flask' icon next to them, and non-standard items have a little 'warning' icon next to them, mirroring MDN conventions.
> Experimental capabilities have a little 'flask' icon next to them, and non-standard items have a little 'warning' icon next to them, mirroring MDN conventions.
This is not true. I haven’t gone through each item in detail, but there are no icons for Web Bluetooth, Web NFC, or Web USB. All of these are non-standard, Blink-only APIs that no other rendering engine has agreed to implement.
Mozilla on Web Bluetooth:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
Reminds me of this very, very classic/epic post [0] by John Carmack on this very topic. Definitely worth a (re-)read.
Steve first talked about application development for iPhone at the same keynote I was demonstrating the new ID Tech 5 rendering engine on Mac, so I was in the front row. When he started going on about “Web Apps”, I was (reasonably quietly) going “Booo!!!”.
After the public cleared out and the rest of us were gathered in front of the stage, I started urgently going on about how web apps are terrible, and wouldn’t show the true potential of the device. We could do so much more with real native access!
Steve responded with a line he had used before: “Bad apps could bring down cell phone towers.” I hated that line. He could have just said “We aren’t ready”, and that would have been fine.
> Nowadays they might as well not exists for iOS/macOS
They work fine for both iOS and macOS. Safari scores higher than Firefox on Android.
Don’t be fooled by scores like this that include non-standard behaviour. Including Blink-only behaviour that both Mozilla and Apple have rejected is obviously going to artificially inflate Chrome’s score.
> Nowadays they might as well not exists for iOS/macOS
PWAs work very well on macOS. I use the PWA version of discord instead of their electron app because it feels a lot more "native" and responsive than the alternative.
It says "popular mobile and desktop browsers" but doesn't include the most popular desktop browser, Chrome? I know it has Chrome for Android, but desktop Chrome supports some extra stuff (Shared Workers, File System Access API) which makes it basically the best browser for PWAs. Feels like that level of popularity and quality should be represented somewhere.
Biggest problem for me as a PWA dev is how eager mobile browsers are to delete your local data, which is not part of this scorecard. I guess that's tricky to quantify, but basically they all suck but Safari sucks more.
Seems like a useful resource to help devs understand PWA support across platforms. Thank you!
I help run PWABuilder.com, which packages PWAs for app stores. I think it would be helpful to our users to see your pwascore.com site. Maybe we can link to your site from ours.
There are a lot of PWAs packaged as mobile apps, probably more than you realize. Google makes this pretty seamless with TWAs, and you can use Capacitor/Cordova on iOS. You can even connect/write your own JavaScript interfaces to native APIs.
FWIW, in the US, PWAs are a non-starter for most apps due to Apple having so much marketshare and having horrendous UX for installing them. Anytime you have to provide your users "instructions" to do something on iOS, you've lost (and it's by design).
It's somewhat popular for piracy, when you know that your site could never pass the Apple/Google store reviews. I've seen it with, for example, manga aggregators
Looks pretty cool. Some comments on usability, It would be handy to see a visual indicator of which capabilities where missing from each browser - maybe you could colour each section heading Green or Red? It would also be handy if you could toggle all open/closed.
It might not be the objective of the owner of that site, but what I'd really like is an updated/maintained subset of what PWA features/components are usable across a selection of browsers - like iOS Safari and stock Android Chrome, Or Chrome/Safari/Firefox on desktop (perhaps filterable by OS too)?
Firefox has the same number of "Unknown" capabilities as Chrome and Safari. These are items which aren't tracked in Can I Use or MDN, and I intend to resolve those ASAP. (I appreciate you calling me out on that.)
A significant number of things on this list are non-standard things that only Google have implemented for Chrome, that no other rendering engine has agreed to implement. Obviously this gives a huge artificial boost to Chrome.
I think comparisons with desktop browsers will be interesting! I intend to make this configurable and let people choose browsers and browser versions, including desktop browsers.
PWAs work well on Desktops, you can install them on Chrome etc and they show up as native apps in Linux and Windows (opening in a chrome window, minus any address bar etc, at least). If you already have a PWA, I don't know what Electron would give you.
You can also ship PWAs on the Microsoft Store and allow Windows 11 folks to natively install them (for an example/shameless plug: https://homechart.app).
You can feel the dev team trying to get as close as they can without shooting their golden goose App Store.
So many apps could be PWA…and we could expect so much more from the median PWA.
BeforeInstallPrompt is non-standard. They removed it from the specification because Mozilla had no plans to support it and Apple wouldn’t commit either.
Here’s the discussion:
> There is also some disagreement on the a `BeforeInstallPrompt()` event (BIP). Despite BIP having been in the spec for a few years, neither Safari nor Firefox have opted to support it. As it stands, Mozilla does not plan to support BIP. We are unsure what WebKit's plans are - @hober maybe could let us know? If WebKit doesn't plan to support it, then we should probably remove it from the spec.
— https://lists.w3.org/Archives/Public/public-webapps-github/2...
So yet again, this is a case of Google wanting something, Google implementing it unilaterally, Google not being able to convince any other rendering engine to implement it, then the non-standard, Blink-only behaviour is being presented in situations like this as if Safari alone is failing to support a standard.
Web standards are not whatever Google wants. They are arrived at through consensus.
Remember the iOS 17.4 thing from February 2024. Apple completely disabled PWAs in the EU, claiming alternative browser engines created insurmountable security problems that would require building "an entirely new integration architecture" that wasn't practical given DMA timelines. Then after two weeks of backlash they reversed it. If the technical barriers were real, how did they solve them in 14 days? That looks less like a technical limitation and more like testing how much they could get away with.
Or push notifications, Safari on macOS got them in 2013. Safari on iOS got them in 2023. Same WebKit engine, same APNs infrastructure, 10 years apart. What's the technical explanation for that gap? And even after iOS finally got push notifications, they only work for PWAs installed to home screen, not in Safari itself. That's a restriction that doesn't exist anywhere else. Android Chrome has had this working in the browser since 2015.
That's the genius of plausible deniability, every individual decision has some technical justification you can point to. BeforeInstallPrompt lacks consensus (true). Safari has limited resources (as has Chrome). Security is hard (definitely true). But the cumulative effect of all these decisions, year after year, is that PWAs on iOS are hobbled compared to native apps in ways that just happen to protect a $20B+ App Store business.
Your fact-check on BeforeInstallPrompt actually demonstrates why the other patterns are harder to explain away. It shows Apple can legitimately decline features through proper standards processes, which makes the decade-long notification delay and the iOS 17.4 reversal look even more suspicious by comparison.
Yes, and this pattern keeps popping up:
- Google wants something
- Google writes a spec.
- Google implements it.
- No other rendering engine wants it.
- It starts popping up on sites like this.
- People complain that it’s Apple’s fault for not implementing the standard.
Google keeps doing this over and over again. This is embrace and extend all over again. Web standards are not whatever Google wants them to be. They need to be arrived at through consensus.
Google gives Mozilla billions and billions of dollars and they still can’t get Mozilla to agree to these things. Google can’t get anybody outside of Google to implement these things.
Stop ignoring the fact that Mozilla is also saying no to a tonne of stuff. Stop ignoring the fact that no other rendering engine wants these things.
This is not “Apple is holding things back”. This is “Google is trying to unilaterally control web standards”.
Again, the iOS 17.4 situation. Apple claimed building PWA support for alternative browser engines wasn't "practical to undertake" due to security architecture requirements. They removed the feature. Two weeks later they brought it back. I'm asking one more time, what changed in those 14 days? If the architecture work genuinely "created insurmountable security problems that would require building "an entirely new integration architecture" that wasn't practical given DMA timelines", how was it completed so quickly?
Push notifications on iOS versus macOS. 2013 on Mac, 2023 on iPhone, same WebKit engine, same APNs backend. Apple controls the browser and the notification system on both platforms. Why the 10 year gap for what should be the same technical implementation? The thing is, whether or not Google tries to control standards doesn't explain these Apple-specific patterns that are clearly driven by Apple's conflict of interest. Mozilla declining BeforeInstallPrompt doesn't explain why features Apple already built for macOS took a decade to reach iOS. These are implementation decisions about Apple's own technology on Apple's own platforms.
You can argue Google is problematic (I'd also agree on that!) and also admit that Apple's decisions around PWAs are clearly driven by their conflict of interest to protect their $20+ billion dollar App Store business model. Those aren't mutually exclusive. But you haven't explained the iOS 17.4 reversal or the notification delay at all. Could you address those specifically?
This scorecard says that Chrome for Android already does pretty well, but how many users use PWAs on Android?
That may have being true a few years ago, but now days unless you are really pushing for very specific stuff GPU stuff. With CSS GPU acceleration its barely noticeable for normal UIs. Now there are tons and tons of PWA that is done in a very in efficient way, then you get a really laggy app.
I'm really tired of hearing this quite frankly, because the reasons as to why that happens to be the case in some scenarios is not "just" a coincidence, which has been explained ad nauseam.
>This scorecard says that Chrome for Android already does pretty well, but how many users use PWAs on Android?
While I've not seen any stats, I personally use them where possible. Interestingly, my boomer Dad, who is completely clueless when it comes to technology, independently discovered them. He has no idea what a "PWA" is, but he always asks me to "make this website an app for me".
That would be a nicer world.
Kinda... Google and folks have been cracking down on security pretty hard, to the point where certain things would probably stop working if you weren't maintaining the security of the endpoint or something correctly. There are APIs (more and more everyday it seems...) that only work with "secure contexts" like HTTPS, and they're working actively on tightening HTTPS requirements (like shortening certificate lifetimes, valid ciphers etc). Sure, this helps improve security, but not without breaking compatibility.
Yes, we need to do this, but it has to be an actual test suite.
People need to be able to contribute tests to expose broken “supported” functionality.
This just perpetuates lies.
Kudos to the author, I have absolutely nothing against your efforts, but the approach is just flawed in my opinion.
The data sources are credited at the bottom, and I feel like they're both gold-standard references. I'm open to suggestions!
I can create a filter for that, thanks for the feedback! Importantly, experimental and non-standard features are not counted in the primary score.
Experimental capabilities have a little 'flask' icon next to them, and non-standard items have a little 'warning' icon next to them, mirroring MDN conventions.
This is not true. I haven’t gone through each item in detail, but there are no icons for Web Bluetooth, Web NFC, or Web USB. All of these are non-standard, Blink-only APIs that no other rendering engine has agreed to implement.
Mozilla on Web Bluetooth:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
— https://mozilla.github.io/standards-positions/#web-bluetooth
Mozilla on Web NFC:
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
— https://mozilla.github.io/standards-positions/#web-nfc
Mozilla on Web USB:
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
— https://mozilla.github.io/standards-positions/#webusb
As far as I can see, you’re counting these Blink-only Google APIs as standards that other browsers are failing to implement.
[0] https://www.reddit.com/r/Games/comments/8l9qw2/comment/dzdwc...
They work fine for both iOS and macOS. Safari scores higher than Firefox on Android.
Don’t be fooled by scores like this that include non-standard behaviour. Including Blink-only behaviour that both Mozilla and Apple have rejected is obviously going to artificially inflate Chrome’s score.
PWAs work very well on macOS. I use the PWA version of discord instead of their electron app because it feels a lot more "native" and responsive than the alternative.
Biggest problem for me as a PWA dev is how eager mobile browsers are to delete your local data, which is not part of this scorecard. I guess that's tricky to quantify, but basically they all suck but Safari sucks more.
I help run PWABuilder.com, which packages PWAs for app stores. I think it would be helpful to our users to see your pwascore.com site. Maybe we can link to your site from ours.
File-sharing services (e.g., sharedrop?) seems to be some of them but I'm not sure if its popular in terms of usage.
FWIW, in the US, PWAs are a non-starter for most apps due to Apple having so much marketshare and having horrendous UX for installing them. Anytime you have to provide your users "instructions" to do something on iOS, you've lost (and it's by design).
Added, thanks! I really like the suggestion to use some kind of indicator in category headings, too.
This feels like a chrome ad
A significant number of things on this list are non-standard things that only Google have implemented for Chrome, that no other rendering engine has agreed to implement. Obviously this gives a huge artificial boost to Chrome.
I know Chrome / Edge kept having issues with it being behind experimental flag and even the flag breaking and going away between builds.
Never heard of Safari supporting tabbed mode for PWA's
This is probably the biggest issue for me with PWA's windows.open actually opening a new full OS window sucks rather than a built in native tab strip.
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
It is not, thank you. Fixed!
Is there not much PWA stuff for desktop or... does it not matter since you can just pin tabs?
You can also ship PWAs on the Microsoft Store and allow Windows 11 folks to natively install them (for an example/shameless plug: https://homechart.app).