Apns (Apple Push Notification Service) Reliability

APNS (Apple Push Notification Service) reliability

1. APNS is based on Apple Servers, and Apple doesn't give any guarantee on successful message delivery.
2. If the app is open (i.e. the user is using the app) while the notification arrives, iOS doesn't show a notification message, you need to handle it.
3. Notification shows up only when the app is backgrounded or killed.
4. Also implement feedback service on your server side; will help you get rid of old unwanted tokens (users who deleted the app or disabled notifications through settings).
5. Don't send too many notifications to a device within a short span of time, because APNS caches only 1 message/device (if the device is offline). So it can deliver the message when the device comes online. Am not sure how long the message is cached though.

Or just implement Pusher... http://pusher.com

Is Apple's push notification service reliable?

The APN service will queue messages up -- but Apple doesn't guarantee delivery of all messages. Only the last message from an application will be kept in the queue when the user is offline. Additionally, old messages may be deleted.

Local and Push Notification Programming Guide

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.

APNS suitability and reliability for emergency notifications

Short answer, no, there is nothing official.

Considering all of the possible points of failure that may lead to a notification not getting delivered, I would say APNS should NOT be considered as an "emergency notification service."

Case-in-point, last year, during Hurricane Sandy, certain carriers used WEA (Wireless Emergency Alerts) to dispatch what looked like simple push notifications but were in fact delivered in a completely different way that, briefly, must be supported by the carrier and has the huge advantage of not being affected by network congestion. You can read more about that here: http://abcnews.go.com/Technology/hurricane-sandy-wireless-emergency-alerts-people/story?id=17612492

Apple Push Notification reliablity

Please find my comments below.Hope this helps.

1. What is the failure rate of push notifications?
   
   
   • Apple has not disclosed it so far.
2. Are push notifications always reliable to send important messages?
   
   
   • Delivery of notifications is a “best effort”, not guaranteed. It is not intended to deliver data to your app, only to notify the user that there is new data available.
   • Please refer - https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
3. Assume that the server which is supposed to send push notifications sends a large number of push notifications every minute. What are the chances of push notification failure in such a case?
   
   
   • 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.
   • Please refer - https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
4. Which circumstances cause push notification delivery to fail?
   
   
   • 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.
   • Please refer - https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html

How to test Apple Push Notifications Feedback Service?

Okay, so from what I have discovered, seems that Instant Feedback service from Apple is working just fine and is able to detect uninstall pretty fast. There was a small trick in how to test these things properly with sandbox service.

If you make an app which you are testing locally on your device and your app is the only one installed on your phone from that provisioning profile (vendor), stuff which I faced as an issue in my question will be encountered. For some reason, even if you uninstall the app (which was the only one on the phone installed from your provisioning profile), Apple is always responding with 200.

What needs to be done is following: After you install your app which you are testing, create a new dummy app with another bundle ID, but which also coming from your provisioning profile, enable push notifications in it as well and install it on your device. So now, you have two apps that you made - one which you are developing and testing the Instant Feedback service with and another one which kinda "zombie" app which just sits in there and does nothing.

After this, uninstall your test app, try to send silent push notification and Apple will respond with status code 410 as expected.

Dummy way, but for some reason that's how it should be while testing. Behaviour in production should be as expected and w/o any need to have a dummy (or any other) app from same vendor installed on iOS device.

Push notifications delivered to apple apns server but device received nothing

Apple doesn't give any guarantee on successful message delivery. you can see related answer here

If you're not seeing Apple push notifications when you're connected to a network, check with your network administrator to make sure related TCP ports are accessible.

To use Apple Push Notification service (APNs), your Mac and iOS clients need a direct and persistent connection to Apple's servers.

iOS devices try to connect to APNs using cellular data first. If the device can't connect to Apple's servers over the cellular connection, it then tries to connect using Wi-Fi.

If you use Wi-Fi behind a firewall or a private Access Point Name (APN) for cellular data, you'll need a direct, unproxied connection to the APNs servers on these ports:

TCP port 5223: For communicating with Apple Push Notification services (APNs)
TCP port 2195: For sending notifications to APNs
TCP port 2196: For the APNs feedback service
TCP port 443: For a fallback on Wi-Fi only, when devices can't reach APNs on port 5223

The APNs servers use load balancing, so your devices won't always connect to the same public IP address for notifications. It's best to allow access to these ports on the entire 17.0.0.0/8 address block, which is assigned to Apple.

APNs stands for the Apple Push Notification service. APN stands for Access Point Name, the gateway between a cellular data network and the Internet.

check this link for same explanation

and also check for How do I troubleshoot issues with Push Notifications on iOS?

---

Related Topics