For this specific use case, it's missing the Web Push API[1], which can be used to implement push notifications, and the Web Notification API[2], which can also be used for the same thing.
Maybe your app is a rare exception, but apart from chat apps, any use of notifications I’ve seen are undesirable and abused to spam users. Even those that do have a legit use-case still abuse it by pushing non-desirable (from user perspective) messages.
I think apart from Gitter I’ve never wanted a notification, as a user.
This app helps sick patients navigate the healthcare system. Notifications were requested by users so that they don't need to continuously go back to the web app to see if there are any updates.
See this post[1]. We already do text and email notifications. Not all phones and tablets get texts, and email notifications are unreliable. Many users wanted desktop and mobile notifications, hence why we implemented them on top of texts and emails.
The speaks to your inexperience making applications - using anecdotes and assumptions about "the average user" to determine what to do is nowhere near as useful as asking your actual users. Real data is better than guesswork.
That's true for the users you've seen. My users all open emails with no problem.
Now do you see why "the average user" isn't useful to determine how to build something? Even if most people suck at using email, in my app it works well.
I agree. Most websites use push notifications for the wrong reasons. This has given them a bad reputation. But when properly used they are certainly powerful and useful.
I use them for some local forums to notify me of replies. Don't want to fill up my inbox for this.
What a weird argument. We're not talking about suspicious blogospam sites asking for notification access here. By the same token, most email sent is spam. Should we stop using email?
Spammy notification requests should be mitigated with better browser guards for requesting them. The fact that there is spam does not somehow invalidate that there are legitimate use cases people want them for.
Here in California, I got updates about my covid19 test results, and my covid19 appointment information, over SMS or a link over SMS.
This includes what vaccine I received, the lot number of its production, plus information from v-safe[1] and reminders to check in telling the government how I feel on days after the vaccine.
I don't like browser notifications, especially on mobile. Maybe it's me but there's no explicit place agreed upon between me and the browser where the browser says "if the site sends a notification, here is where it will be".
Mobile is already bad enough where if you swipe a notification away, well I hope you remembered the icon and the bit of context that was on that notification. Browser notifications just make this worse.
And then there's the whole "will I get a notification if the browser app is closed? What if I get a notification in the middle of the night, will I receive it in the morning? Will it continue to receive notifications if I restart my phone?" kind of questions. Maybe it all just works but I am very untrusting of the whole feature.
Technically, webpush-enabled site starts a service on your phone (read on js service workers) that then asks a browser to accept notifications from some origin and sends permission credentials to that origin. Then it decides for every incoming notification if it is worth popping up (e.g. if a site is a chat and it is already on the screen, there is no need to spam with popups), or if it’s worth a new tab on tap/click, etc. It is a hassle to configure, but then it usually just works. I suspect that your browser has to be running anyway, because a service worker is just a restricted browser env. Push providers may have delayed delivery, at least there is a ttl field in a notification at server-side. Didn’t test that much and only used that in one project, but remote alpha users already reported missing notifications. I have no clue how to debug that, because it simply doesn’t happen (phone config seems okay).
Similarly, I’ve rarely needed web notifications and on the handful of occasions I have they’re of a nature that’s better tied to a desktop/laptop than a phone or tablet.
I'm willing to go as far as to say it's The one feature that's singlehandedly holding back PWAs entirely. Most apps that you use every day needs notifications for one reason another, mainly communication apps, and if you could do them with a web app it'd be a game changer. But Apple is holding us all back and has been for years.
So no, lack of push notifications are not holding back PWAs. They are holding back web developers which choose to aggressively require new features, then get upset when they only work in the browser they tested with (invariably Chrome).
Pretty much none of the apps, native or web I use regularly, need notifications in order to do what I want them to do. It is usually the makers of said apps that really really want notifications as a strategy to increase engagement.
I’m not against web notifications per se, but I’m not buying that most web applications are held back because notifications are actually crucial to them functioning.
I don't understand why Apple is holding anyone back. Just build an app that doesn't work on iOS. There's lots of apps exclusive to iOS and Mac - why not exclusive Android?
If the app really is a game changer, if it's that compelling, Apple will absolutely change its tune.
Because any app that is social in nature (where interactions between users is required really) that can only reach 50% of users does not have 50% of the potential value, it's closer to 0.
As an example, my girlfriend's a nurse, and they have a really bad paging system. Basically, the doctor calls the hospital reception who calls one person who is on call, who calls the second person on call. Of course, this breaks up regularly: the wrong person is called, or they call their boss because they don't know who is on call, and so on.
I thought I would do a PWA to help them out and learn some new things, but it's pretty much impossible on iOS. Now, if 50% of her team cannot use the app, it has no value. You would have to know who has the app or not and call the other ones. It's easier to just keep on calling directly.
> Because any app that is social in nature (where interactions between users is required really) that can only reach 50% of users does not have 50% of the potential value, it's closer to 0.
This wasn’t true 10 years ago when Instagram launched, and was iPhone only for a considerable time.
Clubhouse seems to think it’s not true today either, also iPhone only.
The issue is not very clear to me, but usually people create a group chat for that and simply turn notifications off when not “on call”. Whatsapp, telegram, signal, discord, mailing list, whatever fits more. For automation chat/email bots may be used. Chances are it’s already solved, if you take wider than “PWA or nothing”.
Isn’t the entire point of progressive web apps that they’re tolerant of different features being available or not? That’s ‘progressive enhancement’. Your app is supposed to work if the functionality isn’t there, or equally if it’s there but denied access. You can have it show updates when the user checks the app if that’s what they want.
Complaining a browser doesn’t support a progressive feature is a contradiction in terms!
The app helps sick patients navigate the healthcare system. Users get notifications like "Your prescriptions are ready for pickup" or "Your prescriptions are scheduled for delivery at 5PM", and it's a user requested feature.
Right... isn’t that the whole point of progressive web apps? Users get as many features as their browser supports or they permit? That’s the point.
If your app doesn’t work like that then it’s not progressive... so you can’t complain it doesn’t support your progressive app because it’s not progressive.
Try explaining to users that the feature they want and expect doesn't work for them because their particular browser doesn't support it, despite it working on every other browser and platform.
The only solution I see is telling users to "use the app", which doesn't exist yet.
You tell them it doesn't work on iPhone because of Apple policy such and such and to go complain to Apple if they want the feature.
If enough people do it then maybe things change. If developers continue caving and not letting users know there will be no pressure on Apple.
Remember that we had real time webchat without JavaScript two decades ago, and a lot of other things that would probably turn into some sort of Chrome-only site if invented today.
If you have a solution to giving iOS users the notifications they want via a web app, PWA or not, I'm all ears. We already implement text and email notifications.
The Push API allows for efficient push notifications without polling, I believe, but don't quote me on it. The problem is displaying notifications like you would a message notification on iOS.
It would be opt-in like on every other platform, isn't that enough? As heavyset_go said, it's a huge pain when a user wants a notification and can't enable one.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Push_API
[2] https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...