didReceiveRemoteNotification is not called for every push notification

Question

It seems that if I send multiple push notifications to the same device, at the same time, didReceiveRemoteNotification is not called for every notification sent. Lets say I send 6 notifications, didReceiveRemoteNotification is only called on average 3 times. That's if the app is currently running. BUT if I am outside the app and send 6 push notifications, all will be delivered to the notification center/lock screen. Is this the expected behavior?

Answer 1

That's the expected behavior:

Apple Push Notification service includes a default Quality of Service (QoS) component that performs a store-and-forward function.

If APNs attempts to deliver a notification but the device is offline, the notification is stored for a limited period of time, and delivered to the device when it becomes available.

Only one recent notification for a particular application is stored. If multiple notifications are sent while the device is offline, each new notification causes the prior notification to be discarded. This behavior of keeping only the newest notification is referred to as coalescing notifications.

If the device remains offline for a long time, any notifications that were being stored for it are discarded.

While in your case the device in online, the important thing to note is that only one notification is stored for your app for each device by APNs. Suppose you send 3 notifications at once. The APN server is delivering the first message to the device when the second message arrives. It stores the second message. Then the third message arrives while the first is still being delivered, so the third message overrides the second, and the second is never delivered.

Here another quote which you may find more convincing:

Some Notifications Received, but Not All

If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one.

Here's why. The device or computer acknowledges receipt of each notification. Until the push service receives that acknowledgment, it can only assume that the device or computer has gone off-line for some reason and stores the notification in the quality of service (QoS) queue for future redelivery. The round-trip network latency here is of course a major factor.

As described in the Local and Push Notification Programming Guide, the QoS queue holds a single notification per app per device or computer. If the service receives another notification before the one in the queue is sent, the new notification overwrites the previous one.

All of this points out that the intent is that a notification indicates to an app that something of interest has changed on the provider, and the app should check in with the provider to get the details. Notifications should not contain data which isn't also available elsewhere, and they should also not be stateful.

Any push notification that isn't delivered immediately was queued for future redelivery because your device was not connected to the service. "Immediately" of course needs to take latency for your connection into account. Outlying cases would be beyond 60 seconds as APNs will time out at that point.

Source