You should be delivering the best possible experience for the user based on what their device can do, not the lowest common denominator of some arbitrary set of features. Progressive enhancement, API detection, and polyfilling are all common strategies that can be used to mitigate almost all device differences.
Keyword being "almost", and that in some cases if the platform doesn't support your feature, you're shit outta luck.
By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications support on iOS. There was simply no workaround or polyfill for that at all, and the biggest use case for PWAs was supporting push. Apple finally released web push notification support last year on iOS but the app needs to have already been installed on the home screen (I think that part is good), and last I checked the "install to home screen" on iOS Safari was still a horrible user experience (the actions is hidden under the "share" menu, which makes no sense to me).
Is there any evidence that this moved the PWA needle at all, he said hopefully? I would've predicted no effect on PWA adoption.
> …last I checked the "install to home screen" on iOS Safari was still a horrible user experience (the actions is hidden under the "share" menu, which makes no sense to me).
For better or worse, it's how iOS users are trained to "do something" with the current web page. Keeping in mind that "PWA" is jargon that average users won't be familiar with, what would be easier than (1) tap Share, tap (2) Add to Home Screen?
If I add a PWA or shortcut to my Home Screen, it will quite quickly disappear silently. Especially if I use Chrome to do it. The Support community is at a loss to explain this and they're starting to send me nonsensical instructions, showing they are desperate to get rid of my embarrassing question.
In what universe does "adding to home screen" have anything to do with sharing? It's completely nonsensical.
As others have noted, it would be trivially simple for browser makers to explicitly have something in the address bar or a pop-up that allows users to install.
For me, it was developers trying to push Android design language via PWAs. In others, it was what should have been a website being packaged as a PWA, which is just clunky. That combination made PWAs feel cheap compared to native apps or sites.
What does a website packaged as a PWA mean? A PWA is a website.
So the exact opposite of PWAs.
When I came back to Web/Distributed Systems after my stint dealing with Windows desktop, all the applications I have been involved only had Web frontends, including for mobile devices, not Web views, the actual browser.
They managed perfectly fine.
For subscription app may be, but all ads revenue websites will reject it.
I reject them
I cannot tolerate apps with ads
I think most in-house devs would rather not deal with the app store or the vagaries of getting the MDM side loading pathway working
And that kind of ambiguity is why you need to be using a rigorous source like caniuse and not just looking at summary statements for this kind of information.
I didn’t actually mean to compare BT vs BT audio in my original post, I just picked an example every browser will let you do. I hadn’t considered the crossover until I saw your reply.
Apple laughs at your universal support.
They have tried to hobble the web as a platform for fairly obvious reasons for as long as they could.
They don’t deserve any credit for whatever progress they made, it was done unwillingly at gunpoint.
- Tim Apple, probably
I wonder what kind of preachy "we are so brave" excuse it will be this time now that they're finally forced to allow app sideloading by the EU and Japan.