Remote Notifications delayed on device

We have been getting several reports in the past 2 weeks of APNs notifications being either heavily delayed or not delivered at all.

We have two apps, one of which has a Notification Service Extension and one of which does not. We have had users of both reporting sporadic notification problems.

Looking at the sysdiagnose logs from one example, it looks like the notification was actually processed by our notification extension in a timely fashion, but was not displayed to the user.

An example event we investigated it the following (now perhaps a little long in the tooth):

2025-10-31T14:32:54 apnsId=EE3E002D-26DE-B4F5-5E9B-5E0C1E1B6B3D

We think we have correlated this with device logs: default 2025-10-31 10:32:54.472054 -0400 [EDE9521D-8A65-4588-8AE8-D3D78B9E5EA5] Received replacement content for notification request 859D-ABC7 [ hasContent: 1 attachments: 0 ]

However there is no other reference until the app was launched about 1.5 minutes later:

default 2025-10-31 10:34:26.875327 -0400 [..] Got 1 delivered notifications [ hasCompletionHandler: 1 ]

When trying to reproduce, when I saw notifications bannered, the trace I saw was "Got 0 delivered notifications". What's the significance of "Got 1 delivered notifications" in this case?

Historically, SpringBoard logs have shown detailed trace about the handling of notifications (which was very useful in narrowing down the slowness of notifications due to Apple Intelligence, reported on our side as FB16253547, which doesn't seem to have been triaged but it looks like was resolved around iOS 18.2.1 or iOS 18.3); however it seems that now sysdiagnoses are only containing <1 minute of trace from SpringBoard.

Is there any way to extend the trace from SpringBoard that is included in sysdiagnoses?

I see there was also https://developer.apple.com/forums/thread/806367 around the same time we started receiving reports. However I think my hypothesis is that this is a client-side issue, and notifications are being delivered to devices, just not presented correctly.

Will try and collect a bit more data and file some Feedbacks and provide them here, but wanted to also flag here in case there are any others experiencing similar.

Added FB20993304 for an instance today.

For today's instance, the sysdiagnose is somewhat helpful but because it is redacted for privacy, it is difficult to know what exactly happened in the lifetime of a push. There are debugging profiles that can be installed on devices to un-redact the logs but that is difficult to do on client devices, especially if it is something that happens intermittently.

Although, by matching the timestamp of the problem push, I was able to determine that it was sent to and received by the device within a second.

So, if there were a delay in showing the notification, that happened on the device.

The delays due to Apple Intelligence have been greatly improved, but it is always possible that there could be a glitch.

Are these notifications being shown as received, or is your app using a Notification Service Extension to process them? If so, could there be a delay introduced there?

Also, this device has received 5 notifications during that 10 second time span. How much are we trusting user anecdote for this, and that they are not conflating one notification with another?

Unfortunately without detailed logs we can neither confirm or deny their experience. So, I am not sure how I can be of further assistance without more detailed logs.

If you are able to somewhat consistently reproduce the issue on a device you can add debugging profiles to, then we might be able to dig deeper.


Argun Tekant /  WWDR Engineering / Core Technologies

For the case in FB20993304, the application in question does not have a Notification Service Extension.

We have a sysdiagnose from a previous report in our other application from Oct 31, which does have a Notification Service Extension, and we can see that the notification was processed within the Notification Service Extension in a timely fashion (from both our logs and also trace from the system).

Yesterday, the user we were working with could reproduce consistently. I have asked them to install the APNs logging profile from https://developer.apple.com/bug-reporting/profiles-and-logs/ (which is still labelled as the "FaceTime and Call Activity Logging Profile" at installation time, causing user confusion, xref FB15646353); unfortunately they reported that since installing the profile the delivery delay has abated.

If the user is willing to keep the profile installed, and keep reinstalling it every few days (as the profile will self expire), it would be great to have a full sysdiagnose attached to the Feedback report when the issue repeats.

I see the profile contains

	<key>RemovalDate</key>
	<date>2025-12-22T08:00:00Z</date>

Does that not mean that it is good until 22nd December?

Remote Notifications delayed on device
 
 
Q