iOS 16 web push notifications in 2023

[dfabulich (Dan Fabulich)]

This is almost certainly just Discourse’s doing. They just don’t send notifications if you’ve used the site a certain number of minutes ago. But with no way for end users to see that, it just makes the notifications untrustworthy. But I assure you, I received iOS push notifications for both of these messages. They can work, as long as you know never to trust them.

[jtbayly]

I think the problem is the reverse. Not using the site on my phone recently enough seems to end the receipt of any notifications.

[dfabulich (Dan Fabulich)]

Maybe, but we’re all just guessing. The main thing we need is for Discourse to provide adequate logging to end users. What notifications did Discourse send? What notifications did Discourse decide not to send?

When the PWA receives a notification, it’s allowed to make a local log of that in IndexedDB on the device. Users need to be able to view that log, and correlate it against the server’s log, to see when/if Discourse sent the push but the device didn’t receive it.

But, overall, I’d say: don’t assume the problem is Apple’s fault, and especially don’t assume that just waiting for iOS 18 will help. We need Discourse to do work here, or nothing will ever get better.

[sam (Sam Saffron)]

@dfabulich

What notifications did Discourse send? What notifications did Discourse decide not to send?

This feels like some very very verbose logging to me:

discourse/discourse/blob/cacaa90f4d01452358322ea8b5564f15f4816c74/app/services/post_alerter.rb#L51-L68

A verbose log here, is probably easy enough:

discourse/discourse/blob/cacaa90f4d01452358322ea8b5564f15f4816c74/app/jobs/regular/send_push_notification.rb#L6-L9

"Skipped notifying Sam about “payload” cause Sam was online.

But if you just want to debug this why not set SiteSetting.push_notification_time_window_mins to 0?

And then the next level of logging becomes very very verbose:

1. Skipped notifying cause user had do not disturb enabled
2. Timeout to push notification provider discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
3. Expired sub
4. Response Error

A lot of different things can go wrong… though at any point in time you can probably use DE to validate: look in the push_subscriptions table for up to date web push subs.

[dfabulich (Dan Fabulich)]

Let me begin by saying that from my perspective, the problem is that people are writing in here and on my forum, saying “I think that push notifications don’t work right,” and other users are chiming in, saying, “Yeah! Me, too! Notifications must be broken/unreliable.” Sometimes they blame Apple, sometimes they blame Discourse, but they all agree that Discourse push notifications are unreliable.

I’d love to be able to investigate these cases myself, saying “you didn’t get the 12:31pm notification on your phone, and here’s why…” but I don’t believe that’s currently possible.

@sam

A lot of different things can go wrong…

Yes, a lot of different things can go wrong, including things on the client side, which I can’t investigate in DE.

• Did the Service Worker receive the push event?
• Did the Service Worker call showNotification?
• Was the showNotification permission granted, or did showNotification accomplish nothing?
• Was the device itself set to Do Not Disturb?

@sam

though at any point in time you can probably use DE to validate: look in the push_subscriptions table for up to date web push subs.

I would love to have some documentation for administrators explaining how to use DE to diagnose a push failure, at least in as far as seeing whether the notification went through.

But I think it would also be incredibly helpful to keep a client-side log that users could send to me, allowing me to cross-reference against the DE log.

@sam

But if you just want to debug this why not set SiteSetting.push_notification_time_window_mins to 0?

For one thing, at least half of the people complaining about this aren’t administrators of their forum. That’s why we need Discourse to implement this:

Let users configure their own push notification time window

push_notification_time_window is a site-wide setting; it’s 10 minutes by default. [image] Wait (n) minutes before sending push notification. Helps prevent push notifications from being sent to an active online user. I think this should be a user preference, instead of a site-wide setting. Some users might prefer 0-minute window or 1-minute window (especially when they’re testing push notifications); others might prefer a 10 minute window, or an even longer window.

But, yes, I suspect that setting this to 0 will eliminate 80% of the “it’s not working” complaints.

Overall, user trust in Discourse notifications is quite low. The more researchable this issue is, for administrators (and even for end users), the more trustworthy Discourse notifications will be.

[sam (Sam Saffron)]

@dfabulich

• Did the Service Worker receive the push event?
• Did the Service Worker call showNotification?
• Was the showNotification permission granted, or did showNotification accomplish nothing?

I am a bit confused about this piece, we push to a URL direct from the server…

[dfabulich (Dan Fabulich)]

@sam

I am a bit confused about this piece, we push to a URL direct from the server…

Here’s my reasoning. Look at what users are saying in this thread.

@WorldIsMine

I have to manually disable/enable notifications for them to work. BUT, they only work for a few hours. Virtually all of my members who use the HomeScreen iOS feature experience the same.

@jtbayly

Yeah, I gave up months ago.

Maybe iOS 18 web push notifications in 2024 will do it.

These posts seem to be implying that the problem could be Apple’s fault. Maybe Discourse is pushing to the URL, but then, for some reason, Apple’s not delivering the push. Why could that be?

1. Maybe Apple is returning 4xx or 5xx to the push job, and Discourse needs to re-push.
2. Maybe Apple got the message, but is unable (or unwilling?) to deliver the message to the device.
3. Maybe the device got the message, but Apple’s not firing the push event for the service worker.
4. Maybe the service worker received the push event, but there’s a bug and it didn’t call showNotification (probably not this one, it’d be too obvious…?)
5. Maybe the service worker received the push event and called showNotification, but Apple refused to show a visible notification. There are actually a lot of reasons this might happen:
   • Device is set to Do Not Disturb (but the notification should eventually show up in the Notification Center, in that case, I think)
   • Permission was granted at one point, but is now revoked (the PWA can detect this case and log it!)
   • The user might have configured the app with weird notification settings, so it, like, only pushes to the Notification Center but doesn’t show a banner
   • … or Apple is refusing to show the message for some other policy reason (maybe they think the notification is spam?), and maybe they’ll be more generous in a future version of iOS

And that’s not even considering any of the reasons why Discourse itself might not send the notification (Do not disturb, push filters, push_notification_time_window_mins).

If all we can say is, “Well, at 12:31pm, Discourse fired a notification with ID XXX to Apple, and Apple returned a 201 Created status code, but we have no idea what happened after that,” then these users/administrators will have no way to investigate further. We’ll just have to blame Apple and give up on push notifications. (“Maybe iOS 18 web push notifications in 2024 will do it.”)

Instead, we need to be able to say, “Your on-device logs show that at 12:33pm, the service worker woke up with a push event for notification ID XXX, and fired showNotification, and we can see via the Notification API that Apple says that the permission to showNotification for that XXX push was granted.”

(I also think there should be a “send a test notification” button on the https://meta.discourse.org/my/preferences/notifications page that allows you to schedule a notification in the future, e.g. N minutes or N hours in the future, allowing users to test the “it doesn’t work after a few hours” case.)

[WorldIsMine (DaveK)]

From my end, I couldn’t reproduce this on my staging site. The notifications work there without a problem. The problem is my production site. Notifications stop working in a short few hours every time I enable them. My only theory is that perhaps the volume of push notifications could be a problem? My production site is very active and has over 50K members, so a lot of notifications are being sent to my user account (and in general).

[RGJ (Richard - Communiteq)]

So @WorldIsMine and I did a little experiment.

• we waited until his notifications stopped working
• we verified that his push subscription was still in the push_subscriptions table
• I sent a push notification from the rails console and made sure to log all exceptions

u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)

• there was no exception
• he did not receive it
• (to double check, I was able to send a push notification to myself)

So this is something on Apple’s end? What could it be?

[dfabulich (Dan Fabulich)]

Do y’all have access to a Mac for testing in macOS Safari? You’d be able to set up dev tools to debug the service worker there.

[RGJ (Richard - Communiteq)]

As far as I understand there is no service worker involved here.

[dfabulich (Dan Fabulich)]

No, all web push notifications require a service worker on iOS. Sending web push notifications in web apps and browsers | Apple Developer Documentation

[RGJ (Richard - Communiteq)]

Ok, out of my league, I unfortunately don’t have any experience with this on the client side, and no Mac to my disposal.

At least we have ruled out the server side of things.

[dfabulich (Dan Fabulich)]

Aha! I think I figured out at least one bug with this, filed in a separate thread.

iOS notifications can lose permission to push if the user is currently active

iOS notifications can lose permission to push if the notification is suppressed. Discourse’s code is configured to optionally suppress notifications, and will thereby lose permission to push when this happens three times. Here’s the code for the push-notification service worker. This code has a critical bug in it, at line 178. There, the service worker checks to see if the user is active (i.e. not idle). In that case, the push event returns false without showing a notification. (It also che…

[sam (Sam Saffron)]

As much as I was hoping your fix improves stuff, I am just not sure.

Meta has been deployed with it for a week. I enabled live notifications on my iPhone PWA. Today… they just stopped working.

It was created Jan 5.

I will try debugging this with a script to see what triggers it to break and how long it lasts, but a lot is pointing here towards apple simply having a bug of sorts.

The more I think about this the more I think that Discourse Hub is the solution now for Apple devices.

[jtbayly]

Thanks for tracking this!

Have you clicked through on any notifications? I ask because I wonder whether Apple Automatically turns off Web notifications if you’ve received a certain number of them without clicking on any of them.

[dfabulich (Dan Fabulich)]

We still need these features to analyze the failures:

1. Instructions on how to use the Data Explorer to see push notification history.
2. On-device logs, such that we can extract those logs and correlate them with server-side logs.
   The logs should include the timestamps of all push events, including the full payload, as well as Notification.permission status
3. “Send a test notification” button that queues up a notification for N minutes/hours in the future.

[sam (Sam Saffron)]

Note, my PWA notifications have been working solidly for past 3 weeks on meta

[nathank (Nathan Kershaw)]

Here is a disturbing update, which indicates that we are in for more trouble on this front:

Apple broke web apps in iOS 17 beta and hasn't fixed them

[Nick_Chomey]

FYI, the news that @nathank reported above has been fully confirmed by Apple.

In an act of brazenly malicious compliance with the European Union’s Digital Markets Act, which aims to bring more openness and competition to digital platforms, Apple has decided to kill PWAs in the EU with their upcoming Safari iOS 17.4.

This will prevent installation of PWAs on the home screen, use of push notifications, background sync, and interfere with offline storage and more. And it will have a global impact beyond just the EU, given that businesses will be far less likely to invest in Web Apps, and PWAs in particular, if iPhone users in the EU cannot use them.

I have to figure that this will be a major hindrance to many Discourse communities, and Discourse itself. If that’s the case for anyone, I strongly recommend that you fill out this survey from the Open Web Advocacy group. They are leading the fight against this, working to inform the DMA team of all of the implications of these and other policies on Web development. They are urgently trying to gather testimonials and data from businesses who will be affected by these changes, so that they can give the DMA better information to fight back.

Please visit this page to learn more, fill out their survey about how this impacts your business, and spread the word! It would be particularly excellent if Discourse could make its users aware of the upcoming change, so that they can each connect with OWA to explain how this affects their businesses and communities.

Immediate Action Needed! - Open Web Advocacy