[onion2k]

The whole point of PWAs is to provide cross platforms apps so if a feature isn't available on all/most platforms, I don't think it's fair to say that it's really usable at all in your PWA.

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.

[hn_throwaway_99]

> 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).

[CharlesW]

> By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications support on iOS.

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?

[usrusr]

Companies that already have two copies of their app front-end team will certainly not jump at the first hunch that they might perhaps be substituted by a third line. It's a slow process. But five years from the watershed moment of Apple ending their web push boycott (announced 22, executed 23), I expect a noticeable trend. For now, it's probably just orgs that would start from zero with an app questioning the need for a pair of native apps who might pick PWA over faux-native (electron/tauri wrapping a web UI). And perhaps some who already did faux-native, keep their app-store presence but also offer a third variant of the same running unwrapped in regular browsers.

[ChadNauseam]

Android allows the site to prompt the user to add it to their home screen, which it can do at a time when it makes sense. e.g. the user orders something, then the "add to home screen" pop-up appears and the user can accept with one tap, which they're likely to want to do because they anticipate wanting to check their order status.

[jon-wood]

Sadly this is caught up in the usual conflict of interests. As someone building a PWA I would love a quick and easy method to pop up an install dialogue for the user. Unfortunately as a user of Safari on iOS the last thing I want is for every single website I interact with to be popping install dialogues, and you just know that's going to be as prolific as the current bombardment of requests to subscribe to mailing lists, and on desktop enable push notifications the moment a web page is opened.

[usrusr]

The "natural" UI place for that kind of begging would not be a pop-up, but the head end of the URL bar, where the domain certificate validity is shown. Usually that's also the place where the UI for revoking permissions that are already granted is launched. Assuming the best I suspect that this is already the future plan of browser makers: on both browsers I usr (android chrome and FF on the desktop) hair the begging pop-up point there already, perhaps this is not only done as a hint to the place where the permission can be revoked, but also as training wheels for a less annoying future where the pop-up is replaced with some simple notification state in that place?

[hn_throwaway_99]

As an Android user I don't feel bombarded by install requests, so I don't really know what you're talking about.

[steve1977]

As an iOS user, I would certainly not want websites prompting me for things like that. But I probably also would not want a webshop as an app. That’s a good use for a plain website.

[NoZebra120vClip]

This doesn't work for me. (Android 11, Motorola phone.)

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.

[hn_throwaway_99]

> what would be easier than (1) tap Share, tap (2) Add to Home Screen?

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.

[JumpCrisscross]

> By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications

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.

[amadeuspagel]

What website uses the Android design language? Every website wants to look different, to stand out. A design language can only exist if it's enforced by an app store.

What does a website packaged as a PWA mean? A PWA is a website.

[alternatex]

PWAs are cheap compared to native apps. That's the whole point.

[Longhanks]

> 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.

So the exact opposite of PWAs.

[alternatex]

Technically that's what Progressive means in Progressive Web Apps. That the developer enables features for customers based on the browser API support on their device, inadvertently ending up with software that works differently on every person's device. You might not like it, but that's what peak Chromebook performance looks like.