PWA Browser Scorecards(pwascore.com)
pwascore.com
PWA Browser Scorecards
https://pwascore.com/
85 comments
> 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.
— 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.
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.
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.
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”.
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?
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?
> 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 was genuinely impractical, how was it completed so quickly?
The target changed. The EU rules implied that there was a requirement for parity between Safari and the other browsers. Implementing that parity by adding a tonne of new APIs for other browsers is understandably infeasible to achieve in a short timeframe. Can we agree on that?
So the other option to achieve parity is by removing the functionality from Safari. Which is what they did – in a beta not a release version if I remember correctly. That got a big reaction, and the EU backed off. So Apple no longer had to achieve this parity in a short timeframe, so they could just keep the status quo. And I think we can agree that keeping the status quo is easy to implement, right?
So what we’re really saying here is that adding a load of new APIs is hard, and not adding them is easy. In that light, Apple saying “hey this is hard” and then a few weeks later going “never mind” makes total sense. And since that time, they have been adding a load of new APIs for other browsers to achieve parity – just not on the super short timescale.
> 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?
I don’t believe Apple have ever claimed it was a technical limitation have they? If you ask real users – even here on Hacker News – a bunch of them will say they don’t want websites to send them notifications on their phone. The user demand isn’t as high as you think it is.
> even after iOS finally got push notifications, they only work for PWAs installed to home screen, not in Safari itself.
You will see this in a lot of Apple decisions around web standards. They see visiting a website and installing a PWA as expressions of different levels of trust and they are trying to avoid permission prompt fatigue. Do you want any random website to send you notifications? No. Do you want websites to constantly prompt you for permission? No. If they do that, will lots of users accidentally say yes? Yes. Are the answers to these questions different for something a user explicitly installs? Yes. If you read through the discussions on the web specification proposals, you’ll see this kind of thing come up several times, from Mozilla as well.
> 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.
I definitely think that Apple makes choices that deprioritise the web. But I also think that 90% of the things people here actually complain about are actually reasonable, and it’s only a small minority that are less justifiable. I also think it’s less a case of moustache-twirling “let’s hold the web back to boost native apps” and more “why should we?”
End-users strongly prefer native to web. End-users are not asking for PWAs in meaningful numbers. At this point people often blame Apple for holding PWAs back, but this isn’t the case.
Apple are not holding PWAs back on Android. Google implement all the APIs they feel like on Chrome for Android. PWAs on Android are not held back. PWAS on Android are a best-case scenario for PWAs. But end users still overwhelmingly choose native apps over PWAs on Android.
If PWAs were preferred by users and artificially limited by Apple, then we would see end-users pick PWAs on Android. Developers wouldn’t build native apps on Android so much, they would just build PWA+iOS and skip the native Android implementation. They don’t do that.
The causality is the opposite direction to what you think. Apple aren’t causing PWAs to fail; PWAs failing causes Apple to not care about them.
The target changed. The EU rules implied that there was a requirement for parity between Safari and the other browsers. Implementing that parity by adding a tonne of new APIs for other browsers is understandably infeasible to achieve in a short timeframe. Can we agree on that?
So the other option to achieve parity is by removing the functionality from Safari. Which is what they did – in a beta not a release version if I remember correctly. That got a big reaction, and the EU backed off. So Apple no longer had to achieve this parity in a short timeframe, so they could just keep the status quo. And I think we can agree that keeping the status quo is easy to implement, right?
So what we’re really saying here is that adding a load of new APIs is hard, and not adding them is easy. In that light, Apple saying “hey this is hard” and then a few weeks later going “never mind” makes total sense. And since that time, they have been adding a load of new APIs for other browsers to achieve parity – just not on the super short timescale.
> 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?
I don’t believe Apple have ever claimed it was a technical limitation have they? If you ask real users – even here on Hacker News – a bunch of them will say they don’t want websites to send them notifications on their phone. The user demand isn’t as high as you think it is.
> even after iOS finally got push notifications, they only work for PWAs installed to home screen, not in Safari itself.
You will see this in a lot of Apple decisions around web standards. They see visiting a website and installing a PWA as expressions of different levels of trust and they are trying to avoid permission prompt fatigue. Do you want any random website to send you notifications? No. Do you want websites to constantly prompt you for permission? No. If they do that, will lots of users accidentally say yes? Yes. Are the answers to these questions different for something a user explicitly installs? Yes. If you read through the discussions on the web specification proposals, you’ll see this kind of thing come up several times, from Mozilla as well.
> 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.
I definitely think that Apple makes choices that deprioritise the web. But I also think that 90% of the things people here actually complain about are actually reasonable, and it’s only a small minority that are less justifiable. I also think it’s less a case of moustache-twirling “let’s hold the web back to boost native apps” and more “why should we?”
End-users strongly prefer native to web. End-users are not asking for PWAs in meaningful numbers. At this point people often blame Apple for holding PWAs back, but this isn’t the case.
Apple are not holding PWAs back on Android. Google implement all the APIs they feel like on Chrome for Android. PWAs on Android are not held back. PWAS on Android are a best-case scenario for PWAs. But end users still overwhelmingly choose native apps over PWAs on Android.
If PWAs were preferred by users and artificially limited by Apple, then we would see end-users pick PWAs on Android. Developers wouldn’t build native apps on Android so much, they would just build PWA+iOS and skip the native Android implementation. They don’t do that.
The causality is the opposite direction to what you think. Apple aren’t causing PWAs to fail; PWAs failing causes Apple to not care about them.
@dang can you please review these coordinated false flags? thank you!
You may want to email [email protected]. It's not clear if the string @dang does anything.
Thank you! Done.
> I need to address several evasions and fabrications of yours here with actual evidence.
> Source this immediately.
> That's pure gaslighting
> You are now dictating how I have to adjust the style of my writing so you can be bothered to finally answer my questions after you've repeatedly evaded answering question? You never had any intention of answering them. Apple's conflict of interest which you're hellbent on denying is indicative of your own conflict of interest. Shareholders tend to be defensive of their own investments.
> You evaded and dodged questions by Gish galloping and didn't expect that I would relentlessly press you on answering them. After you've realized that I will not give up on demanding substantiated answers to those inconvenient questions, you pivoted to arguing about tone. Your strategy is obvious.
> @dang can you please review these coordinated false flags?
You are being flagged because you are dragging this thread down into the mud. Note that your earlier comments where you were behaving more reasonably are not flagged, but as you descend into baseless accusations and conspiracies, your comments are getting flagged.
I pointed you to the site guidelines before:
https://news.ycombinator.com/newsguidelines.html
If you make more of an effort to follow them, you might not get your comments flagged so much. But more importantly, you would stop making this thread an unpleasant distraction from the main topic.
> Source this immediately.
> That's pure gaslighting
> You are now dictating how I have to adjust the style of my writing so you can be bothered to finally answer my questions after you've repeatedly evaded answering question? You never had any intention of answering them. Apple's conflict of interest which you're hellbent on denying is indicative of your own conflict of interest. Shareholders tend to be defensive of their own investments.
> You evaded and dodged questions by Gish galloping and didn't expect that I would relentlessly press you on answering them. After you've realized that I will not give up on demanding substantiated answers to those inconvenient questions, you pivoted to arguing about tone. Your strategy is obvious.
> @dang can you please review these coordinated false flags?
You are being flagged because you are dragging this thread down into the mud. Note that your earlier comments where you were behaving more reasonably are not flagged, but as you descend into baseless accusations and conspiracies, your comments are getting flagged.
I pointed you to the site guidelines before:
https://news.ycombinator.com/newsguidelines.html
If you make more of an effort to follow them, you might not get your comments flagged so much. But more importantly, you would stop making this thread an unpleasant distraction from the main topic.
>You are being flagged because you are dragging this thread down into the mud.
You're projecting and the quotes of mine you've listed are an adequate description of your debate strategy. Then you condescendingly link to the guidelines as if you weren't the one who broke them in the first place by consistently arguing in bad faith.
You're projecting and the quotes of mine you've listed are an adequate description of your debate strategy. Then you condescendingly link to the guidelines as if you weren't the one who broke them in the first place by consistently arguing in bad faith.
(my response for those who missed it https://pastebin.com/mrDgdVZG)
You're ignoring something important. Apple recently threatened stopping EU shipments rather than DMA compliance (https://www.theguardian.com/technology/2025/sep/25/apple-cal...). They want the DMA repealed, have delayed features, and stated "EU users' experience on Apple products will fall further behind." So it's clear that Apple never had any genuine intention of proper compliance from the start, that's why they kept violating it until they couldn't any longer and then Apple switched to demanding the DMA be repealed completely.
Can you also please cite your "EU backed off" claim? Apple reversed following developer/user backlash. If the EU changed position, kindly link to their statement.
Where's your source for the iOS 17.4 "parity" claim? Apple stated "complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake." That's about security architecture and engineering, not browser parity.
Notice what's happening? iOS 17.4 brought PWA removal, security citations, pressure reversal. Currently we're seeing product withdrawal threats, security citations, DMA court fights, market hostage situations. You claim this company lacks conflict of interest and makes neutral web standards technical decisions?
I need a straight answer. Does Apple have a conflict of interest? They run a $20+ billion App Store taking 15-30% of transactions. PWAs let developers bypass it. Do you acknowledge this financial incentive structure exists, or are you still seriously claiming that Apple has no motivation to limit PWA capabilities?
Your argument needs us to believe Apple's PWA underinvestment decade, iOS 17.4 reversal, EU threats, DMA battles, and Android gaps are coincidental technical decisions unrelated to App Store revenue. That's not plausible.
The push notification logic contradicts itself. You claim users don't want them, Apple didn't implement for a decade, then implemented in 2023. Why would they do that? No demand doesn't justify engineering resources. macOS Safari got them in 2013. Low demand doesn't explain that. You haven't explained the 10-year gap between identical technology stacks.
The Android argument supports our point. PWAs need iOS support for developer economics. Without iPhone access, cross-platform value collapses. Developers can't justify PWA investment without iOS access. Saying "PWAs fail on Android" while iOS is hobbled shows exactly what we're arguing about Apple gatekeeping shaping ecosystems.
You claimed "PWAs failing causes Apple not to care." That reverses causality in a deceptive manner. Apple's underinvestment, iOS 17.4 obstruction, decade of gaps cause PWA struggles. You point to that struggle justifying the behavior. That's circular reasoning absolving Apple of responsibility for a situation they created.
You've shifted explanations three times. Google embrace-and-extend, then "parity requirements," then "user preferences" (for which you provided no data), now Android dynamics proving our gatekeeper point. Each time evidence contradicts, new apologia emerges. That's motivated reasoning protecting predetermined conclusions, not reasoned argument.
I'm asking directly. Does Apple's App Store create a PWA development financial conflict of interest? Yes or no? Your writing requires ignoring incentive structures, believing Apple makes innocuous technical choices while fighting regulations, threatening exits, and maintaining decade-long feature gaps that 'coincidentally' always happen to protect their most profitable business.
Can you also please cite your "EU backed off" claim? Apple reversed following developer/user backlash. If the EU changed position, kindly link to their statement.
Where's your source for the iOS 17.4 "parity" claim? Apple stated "complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake." That's about security architecture and engineering, not browser parity.
Notice what's happening? iOS 17.4 brought PWA removal, security citations, pressure reversal. Currently we're seeing product withdrawal threats, security citations, DMA court fights, market hostage situations. You claim this company lacks conflict of interest and makes neutral web standards technical decisions?
I need a straight answer. Does Apple have a conflict of interest? They run a $20+ billion App Store taking 15-30% of transactions. PWAs let developers bypass it. Do you acknowledge this financial incentive structure exists, or are you still seriously claiming that Apple has no motivation to limit PWA capabilities?
Your argument needs us to believe Apple's PWA underinvestment decade, iOS 17.4 reversal, EU threats, DMA battles, and Android gaps are coincidental technical decisions unrelated to App Store revenue. That's not plausible.
The push notification logic contradicts itself. You claim users don't want them, Apple didn't implement for a decade, then implemented in 2023. Why would they do that? No demand doesn't justify engineering resources. macOS Safari got them in 2013. Low demand doesn't explain that. You haven't explained the 10-year gap between identical technology stacks.
The Android argument supports our point. PWAs need iOS support for developer economics. Without iPhone access, cross-platform value collapses. Developers can't justify PWA investment without iOS access. Saying "PWAs fail on Android" while iOS is hobbled shows exactly what we're arguing about Apple gatekeeping shaping ecosystems.
You claimed "PWAs failing causes Apple not to care." That reverses causality in a deceptive manner. Apple's underinvestment, iOS 17.4 obstruction, decade of gaps cause PWA struggles. You point to that struggle justifying the behavior. That's circular reasoning absolving Apple of responsibility for a situation they created.
You've shifted explanations three times. Google embrace-and-extend, then "parity requirements," then "user preferences" (for which you provided no data), now Android dynamics proving our gatekeeper point. Each time evidence contradicts, new apologia emerges. That's motivated reasoning protecting predetermined conclusions, not reasoned argument.
I'm asking directly. Does Apple's App Store create a PWA development financial conflict of interest? Yes or no? Your writing requires ignoring incentive structures, believing Apple makes innocuous technical choices while fighting regulations, threatening exits, and maintaining decade-long feature gaps that 'coincidentally' always happen to protect their most profitable business.
kelthuzad(1)
kelthuzad(1)
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.
> Should we really care what the rendering engines want?
Yes. Let’s use Web MIDI as an example. This was proposed by Google, and implemented by Google. It was initially rejected by both Mozilla and Apple on privacy and security grounds. Mozilla eventually gave in and implemented it. Then it came to light that porn sites had been using Web MIDI to fingerprint and track users.
https://news.ycombinator.com/item?id=23679063
I think Apple made the right call there. Just blindly saying yes to functionality is not good for the web.
Yes. Let’s use Web MIDI as an example. This was proposed by Google, and implemented by Google. It was initially rejected by both Mozilla and Apple on privacy and security grounds. Mozilla eventually gave in and implemented it. Then it came to light that porn sites had been using Web MIDI to fingerprint and track users.
https://news.ycombinator.com/item?id=23679063
I think Apple made the right call there. Just blindly saying yes to functionality is not good for the web.
I sort of agree with Safari's call - a lot of Chrome's functionality is declined by Safari on reasons that it enables fingerprinting. For that reason I think the site is misleading in its rating of privacy.
But I don't think Google's to blame for making a different choice about it. It's picking a different privacy / functionality trade-off, but it's doing it with open standards that others are free to implement if they want.
It's putting some pressure on Apple because users often care more about functionality than about privacy, but not so much that they're worried about it, I think. They seem to be doing well!
But I don't think Google's to blame for making a different choice about it. It's picking a different privacy / functionality trade-off, but it's doing it with open standards that others are free to implement if they want.
It's putting some pressure on Apple because users often care more about functionality than about privacy, but not so much that they're worried about it, I think. They seem to be doing well!
This. PWA is the end of 75% of apps being in the app store
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?
That would be a nicer world.
That would be a nicer world.
Seems doubtful to me. Native apps just tend to feel better.
This scorecard says that Chrome for Android already does pretty well, but how many users use PWAs on Android?
This scorecard says that Chrome for Android already does pretty well, but how many users use PWAs on Android?
>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.
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".
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".
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.
HarmonyoS has started the ball rolling.
HarmonyOS started it? What? Not Android?
Wasnt it Apple that famously came up with the concept, back before they introduced the app store?
They only started back paddling after the app store was introduced and consequently crystalized into a multi billion $ market
They only started back paddling after the app store was introduced and consequently crystalized into a multi billion $ market
“PWA” is a bit of a nebulous concept, but it basically grew out of this blog post by Alex Russell, who was working at Google at the time:
https://infrequently.org/2015/06/progressive-apps-escaping-t...
When Apple launched the iPhone, Steve Jobs told people that if they wanted to build apps for the iPhone, they should build them as web apps. This wasn’t specifically about PWAs, just web apps in general. Users demanded native apps, so Apple launched the iPhoneOS SDK and App Store the next year.
https://infrequently.org/2015/06/progressive-apps-escaping-t...
When Apple launched the iPhone, Steve Jobs told people that if they wanted to build apps for the iPhone, they should build them as web apps. This wasn’t specifically about PWAs, just web apps in general. Users demanded native apps, so Apple launched the iPhoneOS SDK and App Store the next year.
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.
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.
Tabbed Application Mode is really supported across all three?
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...
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...
> Tabbed Application Mode is really supported across all three?
It is not, thank you. Fixed!
It is not, thank you. Fixed!
Ah, I was curious about this too... but now it says that none of them support it. Surely at least one has to support it or else it wouldn't be a feature right? MDN says Chrome only...
Not sure what the deal is with Chrome and tabbed mode, it has had a very long development cycle and it has to be turned on with experimental flag, and that keeps getting broken.
https://issues.chromium.org/issues/393149332
Not sure why there isn't more traction here, tabs is the biggest thing holding back PWA's for me.
https://issues.chromium.org/issues/393149332
Not sure why there isn't more traction here, tabs is the biggest thing holding back PWA's for me.
Seems like its chromeOS only for now.
I’ve always thought it funny how PWAs were pushed by Apple of all people in the beginning. Nowadays they might as well not exists for iOS/macOS
Reminds me of this very, very classic/epic post [0] by John Carmack on this very topic. Definitely worth a (re-)read.
[0] https://www.reddit.com/r/Games/comments/8l9qw2/comment/dzdwc...
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.
[0] https://www.reddit.com/r/Games/comments/8l9qw2/comment/dzdwc...
> 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.
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.
I guess I should have made clear that I don’t have much experience with macOS, but I stand by them being useless on iOS.
Last time I tried developing a PWA-first app on iOS it was horrible. Users couldn’t figure out how to install it, notifications, workers, haptics, etc had all sorts of arbitrary restrictions.
Last time I tried developing a PWA-first app on iOS it was horrible. Users couldn’t figure out how to install it, notifications, workers, haptics, etc had all sorts of arbitrary restrictions.
> Don’t be fooled by scores like this that include non-standard behaviour.
Scores intentionally do not include non-standard or experimental capabilities. I'll make that clearer, thank you!
Scores intentionally do not include non-standard or experimental capabilities. I'll make that clearer, thank you!
> 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.
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.
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.
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.
Yes, please! My email is in my profile in case you need anything.
This site is harmful.
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.
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.
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!
The data sources are credited at the bottom, and I feel like they're both gold-standard references. I'm open to suggestions!
The caniuse test suite is the most basic tests of each feature. Self admittedly it does not actually verify the feature meets any spec.
If you just did what they have but make it actually test to the spec, it’d be great.
“Caniuse” is not gold standard. It’s basically “Did the browser vendor claim to support a feature”.
iOS safari has so many bugs throughout everything on the web, if you actually have them red for every feature with a bad bug, they’d have so much worse of a score.
Eg. Does safari support audio element? Yes on the surface. But try to play from a cached blob. It’s hilariously broken.
See my comment history, there’s an app with a LONG list of safari media bugs. Yet your page lists them with a green check. Lies.
I’m not surprised if nearly every feature there “works” but try to build an app with it and you find yourself set up to fail.
If you just did what they have but make it actually test to the spec, it’d be great.
“Caniuse” is not gold standard. It’s basically “Did the browser vendor claim to support a feature”.
iOS safari has so many bugs throughout everything on the web, if you actually have them red for every feature with a bad bug, they’d have so much worse of a score.
Eg. Does safari support audio element? Yes on the surface. But try to play from a cached blob. It’s hilariously broken.
See my comment history, there’s an app with a LONG list of safari media bugs. Yet your page lists them with a green check. Lies.
I’m not surprised if nearly every feature there “works” but try to build an app with it and you find yourself set up to fail.
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.
> Remove all the non-standard stuff.
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.
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.
— 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.
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.
Thank you so much! The root cause was a logic error on my part, now fixed. The scores are now notably better thanks to your comment.
Did you manually change the status of those particular things? Because that’s not what I was getting at.
All I did was look at the most common things I know off the top of my head are mistaken for web standards when they are not. I did not review anything else. So if you just changed the status of those things, there’s more fixes you need to make.
For instance, I just took another look, and I saw that BackgroundSync is not marked as non-standard. But Mozilla are negative on it:
> We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed.
— https://mozilla.github.io/standards-positions/#background-sy...
And Apple have concerns and have not committed to it either:
> Adding concerns: power as generally having activity running in the background is not great for battery life. In my experience as a user of "native" apps this can also be tricky to get right. Sometimes background syncing would have taken place, but the moment you open the app it does another sync and blows away the content you just started to read.
> Adding concerns: privacy as this would allow a website to monitor you switching IP addresses. As the draft notes there also some network attacker leaks due to this, revealing origins that you visit that use this functionality to them.
— https://github.com/WebKit/standards-positions/issues/14
If you look at the spec. it has “Unofficial draft” displayed very prominently all over it, and also states:
> It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/background-sync/spec/
So again, this seems to be a Blink-only API that only Google have implemented, not standard functionality. How many of these fails are actually just Google doing their own thing with no buy-in from other rendering engines? “PWAscore” is a reasonable thing to build, but “Chromescore” where you measure against all the non-standard things Google have implemented by themselves is not a reasonable thing to build.
Also, you have “Not supported” for push notifications in Safari, but if you check Can I Use, you will see that it works for installed PWAs and is only unavailable to websites you visit. Since the purpose of your site is to score based on PWA support, this should be a success, not a fail.
Personally, I would remove all the non-standard stuff. Not give a big list of standard and non-standard stuff mixed together.
All I did was look at the most common things I know off the top of my head are mistaken for web standards when they are not. I did not review anything else. So if you just changed the status of those things, there’s more fixes you need to make.
For instance, I just took another look, and I saw that BackgroundSync is not marked as non-standard. But Mozilla are negative on it:
> We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed.
— https://mozilla.github.io/standards-positions/#background-sy...
And Apple have concerns and have not committed to it either:
> Adding concerns: power as generally having activity running in the background is not great for battery life. In my experience as a user of "native" apps this can also be tricky to get right. Sometimes background syncing would have taken place, but the moment you open the app it does another sync and blows away the content you just started to read.
> Adding concerns: privacy as this would allow a website to monitor you switching IP addresses. As the draft notes there also some network attacker leaks due to this, revealing origins that you visit that use this functionality to them.
— https://github.com/WebKit/standards-positions/issues/14
If you look at the spec. it has “Unofficial draft” displayed very prominently all over it, and also states:
> It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/background-sync/spec/
So again, this seems to be a Blink-only API that only Google have implemented, not standard functionality. How many of these fails are actually just Google doing their own thing with no buy-in from other rendering engines? “PWAscore” is a reasonable thing to build, but “Chromescore” where you measure against all the non-standard things Google have implemented by themselves is not a reasonable thing to build.
Also, you have “Not supported” for push notifications in Safari, but if you check Can I Use, you will see that it works for installed PWAs and is only unavailable to websites you visit. Since the purpose of your site is to score based on PWA support, this should be a success, not a fail.
Personally, I would remove all the non-standard stuff. Not give a big list of standard and non-standard stuff mixed together.
> Did you manually change the status of those particular things?
No, for the specific issue you mentioned, I found and fixed a logic bug. There are some features/capabilities which are manually assigned in cases where there's no CanIUse or MDN data. (Generally, I'm trying to minimize additions/overrides for maintainability's sake.)
> For instance, I just took another look, and I saw that BackgroundSync is not marked as non-standard. But Mozilla are negative on it: […] And Apple have concerns and have not committed to it either:
This is a very fair point, and again I think you for being very generous with your time and expertise. I've reported this as a bug in the data (https://github.com/mdn/content/issues/41455), and manually overridden the data for now as a workaround.
> Personally, I would remove all the non-standard stuff. Not give a big list of standard and non-standard stuff mixed together.
I've added a "Hide Experimental" checkbox, which can also be set/shared in a URL property. I'm not yet sure about making that the default, but I hope it's useful!
No, for the specific issue you mentioned, I found and fixed a logic bug. There are some features/capabilities which are manually assigned in cases where there's no CanIUse or MDN data. (Generally, I'm trying to minimize additions/overrides for maintainability's sake.)
> For instance, I just took another look, and I saw that BackgroundSync is not marked as non-standard. But Mozilla are negative on it: […] And Apple have concerns and have not committed to it either:
This is a very fair point, and again I think you for being very generous with your time and expertise. I've reported this as a bug in the data (https://github.com/mdn/content/issues/41455), and manually overridden the data for now as a workaround.
> Personally, I would remove all the non-standard stuff. Not give a big list of standard and non-standard stuff mixed together.
I've added a "Hide Experimental" checkbox, which can also be set/shared in a URL property. I'm not yet sure about making that the default, but I hope it's useful!
[deleted]
Why is Firefox marked as "unknown" for many easily findable settings/capabilities? (Ex: https requirement)
This feels like a chrome ad
This feels like a chrome ad
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.)
> 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.
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.
"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.
Fair point. Any thoughts on whether it makes sense for this page to reflect that, and if so, how?
The MDN links in the first section are failing for me - for example, Start URL takes me to https://developer.mozilla.org/en-US/docs/Web/html/manifest/s... which says "Sorry, the page /en-US/docs/Web/html/manifest/start_url could not be found."
(One of the search options on the 404 page goes to a possible PWA-related page, but it's also marked as "Limited" there.)
(One of the search options on the 404 page goes to a possible PWA-related page, but it's also marked as "Limited" there.)
Fixed! I switched to a more reliable method of generating these URLs. Thank you for taking the time to try the site and reporting back!
Confirmed that it now works for me. Thanks! (I'm sort of using it as a "what can PWA's do" study guide for My First Android PWA, so the section organization is almost as big a deal as the "does it even work" indicators - seeing "App Icon Badges: unsupported" does tell me that I don't need to bother figuring out what those even are, I can move on to something else.)
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.
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.
Are there any popular PWA-only apps without a mobile app counterpart?
File-sharing services (e.g., sharedrop?) seems to be some of them but I'm not sure if its popular in terms of usage.
File-sharing services (e.g., sharedrop?) seems to be some of them but I'm not sure if its popular in terms of usage.
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).
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)?
I really like those ideas for filtering, thank you!
> It would also be handy if you could toggle all open/closed.
Added, thanks! I really like the suggestion to use some kind of indicator in category headings, too.
Added, thanks! I really like the suggestion to use some kind of indicator in category headings, too.
This page oversteps the definition of PWA and seems to be more like QuirksMode for advanced features.
For example, is AR/VR a critical PWA feature or is that just advanced capability?
Where does PWA end and "replaces any conceivable native app" begin?
For example, is AR/VR a critical PWA feature or is that just advanced capability?
Where does PWA end and "replaces any conceivable native app" begin?
It's an interesting question. Where do you think the line should be?
I think I understand the deeper point you're trying to make, which is that not all web platform capabilities are created equal when it comes to making PWAs a legitimate alternative to native apps.
I've tried to be thoughtful about this, and my solution was to weight the capabilities from 0.5–3. At the two ends of that range, I gave required PWA features a weight of 3, and nice-to-have/experimental features a weight of 0.5. As you can see, this doesn't really penalize Chrome for its "stunt features", and I think it provides a more realistic picture of what Firefox and Safari are capable of for most PWA use cases.
Additionally, experimental and non-standard features aren't used to compute the PWAscore. You can see raw scores (unweighted, and including experimental/non-standard features) in the tooltip of the "normal" score.
I think I understand the deeper point you're trying to make, which is that not all web platform capabilities are created equal when it comes to making PWAs a legitimate alternative to native apps.
I've tried to be thoughtful about this, and my solution was to weight the capabilities from 0.5–3. At the two ends of that range, I gave required PWA features a weight of 3, and nice-to-have/experimental features a weight of 0.5. As you can see, this doesn't really penalize Chrome for its "stunt features", and I think it provides a more realistic picture of what Firefox and Safari are capable of for most PWA use cases.
Additionally, experimental and non-standard features aren't used to compute the PWAscore. You can see raw scores (unweighted, and including experimental/non-standard features) in the tooltip of the "normal" score.
Honestly, I have no idea. Maybe categorizing things into MVP, standard, and advanced would be a good start.
When I think of most apps on my phone, these capabilities are rare or non-existent:
- USB
- AV/VR
- Payment processing or IAP (almost certainly my own tastes here tho)
- Window management(?) - I'm not even sure what this means on mobile.
But obviously, whatever deficiencies exist in background work or notifications are probably important. Looking at CIU, Firefox seems to have resolved them in more recent versions. In fact maybe some other comment has already mentioned it but FF/Android 141+ seems to have resolved a lot of those?
When I think of most apps on my phone, these capabilities are rare or non-existent:
- USB
- AV/VR
- Payment processing or IAP (almost certainly my own tastes here tho)
- Window management(?) - I'm not even sure what this means on mobile.
But obviously, whatever deficiencies exist in background work or notifications are probably important. Looking at CIU, Firefox seems to have resolved them in more recent versions. In fact maybe some other comment has already mentioned it but FF/Android 141+ seems to have resolved a lot of those?
Oh cool, I was wondering about this.
Is there not much PWA stuff for desktop or... does it not matter since you can just pin tabs?
Is there not much PWA stuff for desktop or... does it not matter since you can just pin tabs?
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.
Because they'd rather wrap it in Electron and farm system telemetry at that point.
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 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.