I am sending notifications to apns one after the other just to test it. For example I send 20 notifications. Each time I send, a counter is incremented and its value is added to the beginning of the title in order to track delivery. The phone receives the first 5 and the 16th but none else.
I am not getting an error for any of them from the apns. They all receive success response.
Why could this be?
EDIT (some extra info):
I am communicating directly with https://api.push.apple.com. I am using http2 and jwtToken. And as suggested, I am keeping the connection alive.
EDIT2:
Device is not offline during this period.
Well, if you send the notifications in a short time period, some may be discarded, especially if the device was temporarily offline when some of the notifications were sent.
Apple Push Notification service includes a Quality of Service (QoS) component that performs a store-and-forward function. If APNs attempts to deliver a notification and the destination device is offline, APNs stores the notification for a limited period of time and delivers it when the device becomes available again. This component stores only the most recent notification per device and per app. If a device is offline, sending a notification request targeting that device causes the previous request to be discarded. If a device remains offline for a long time, all its stored notifications in APNs are discarded.
(Source)
Your app should never depend on all the notifications being delivered.
Related
Problem Statement : I'm using voip notification to show local notification.I'm trying to send notification from Apns to a offline device. So, It queued all pending notifications. But, It only send last queued notification once device becomes
online.
As per apple documentation Link
Quality of Service, Store-and-Forward, and Coalesced Notifications
Apple Push Notification service includes a Quality of Service (QoS)
component that performs a store-and-forward function. If APNs attempts
to deliver a notification and the destination device is offline, APNs
stores the notification for a limited period of time and delivers it
when the device becomes available again. This component stores only
the most recent notification per device and per app. If a device is
offline, sending a notification request targeting that device causes
the previous request to be discarded. If a device remains offline for
a long time, all its stored notifications in APNs are discarded.
To allow the coalescing of similar notifications, you can include a
collapse identifier within a notification request. Normally, when a
device is online, each notification request that you send to APNs
results in a notification delivered to the device. However, when the
apns-collapse-id key is present in your HTTP/2 request header, APNs
coalesces requests whose value for that key is the same. For example,
a news service that sends the same headline twice could use the same
collapse identifier value for both requests. APNs would then coalesce
the two requests into a single notification for delivery to the
device.
I want to send push notification to app users. Users whom online will receive it immediately, right?. But what about users whom offline? Will they get notification after they become online?
Can you tell me more about than push notifications will de delivered?
Are messengers use pushes to send notifications about new messages?
Not possible in offline.
Check it: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
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 QoS stores the notification. It retains only one notification per application on a device: the last notification received from a provider for that application. When the offline device later reconnects, the QoS forwards the stored notification to the device. The QoS retains a notification for a limited period before deleting it.
If a device remains offline for a long time, all notifications that were being stored for it are discarded; when the device goes back online, none of the notifications are displayed.
Basically Apple will try to deliver the notification when the device will become online again (in a resonable time frame).
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 destination device is offline, APNs stores the notification for a limited period of time and delivers it to the device when the device becomes available.
From https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9
Is it possible to send multiple (10 - 15) notifications to the registered iOS users at a time / instantaneously ? What are the limitations for iOS Push Notifications ?
Is it possible to send multiple (10 - 15) notifications to the registered iOS users at a time / instantaneously ?
No you can not send 10-15 notification simultaneously to same user, read more here at apple docs .
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.
However if you intend to send push notifications to different users at same time than it should be no problem (Which i guess is what you are looking for).
What are the limitations for iOS Push Notifications ?
If you are not sending them simuntanously to same user than there is no limitation for APN's push notification as mentioned here .Take a look at Push Notification Throughput and Error Checking
There are no caps or batch size limits for using APNs. The iOS 6.1
press release stated that APNs has sent over 4 trillion push
notifications since it was established. It was announced at WWDC 2012
that APNs is sending 7 billion notifications daily.
If you're seeing throughput lower than 9,000 notifications per second,
your server might benefit from improved error handling logic.
Here's how to check for errors when using the enhanced notification
format. Keep writing until a write fails. If the stream is ready for
writing again, resend the notification and keep going. If the stream
isn't ready for writing, see if the stream is available for reading.
If it is, read everything available from the stream. If you get zero
bytes back, the connection was closed because of an error such as an
invalid command byte or other parsing error. If you get six bytes
back, that's an error response that you can check for the response
code and the ID of the notification that caused the error. You'll need
to send every notification following that one again.
Once everything has been sent, do one last check for an error
response.
It can take a while for the dropped connection to make its way from
APNs back to your server just because of normal latency. It's possible
to send over 500 notifications before a write fails because of the
connection being dropped. Around 1,700 notifications writes can fail
just because the pipe is full, so just retry in that case once the
stream is ready for writing again.
Hope this helps.
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.
for more info click here
I'm testing Apple push notifications for our iPhone app. The app deployment target is 6.1 and the iPhone is running 7.1.1. We use Apigee as our push notification provider. The phone receives notifications when it's online via cellular and wi-fi, confirming that registration is correct on the app side and Apigee side. I turn on Airplane mode, push a notification from Apigee, wait 3 minutes, take the phone out of Airplane mode, and the phone never receives the push notification. I wait a few minutes (up to 30), then push another notification from Apigee and the phone receives the notification.
I've read Apple's Local and Push Notification Programming Guide and I've read Technical Note TN2265 Troubleshooting Push Notifications.
According to the troubleshooting guide, "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." This is why I wait 3 minutes. I also know that APNS queues a single message and I think I know that I'm not overwriting that message - unless latency/throughput with the APNS QoS queue is much worse than a few minutes.
In Apigee, in Message History, I see the notification that was sent when the phone was offline. It has a status of Finished with total sent: 1, total errors: 0. I also see a receipt under Data/receipts. This seems to indicate Apigee successfully sent the notification to APNS (but I'm not 100% sure). I verified that the notifierId from Apigee is the same for all notifications sent when online and offline.
Is there any technique I can use to see why the notification is not being delivered from APNS? Is there anything else I can check?
You are correct, if the Notification is showing no errors and a Receipt has been created, the message was properly delivered to APNS.
The only thing I can think of outside of any vagaries of APNS itself that can affect your delivery is if you set the "expire" property on your Notification. Have you tried to see if that makes any difference to your result?
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?
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