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?
Related
Our application uses APNS push notifications to notify our clients about some change on server or if there is any new message for the user. Many of our clients have complaint us that if they keep the app or phone idle for long time(that is, doesn't open our app for long time) and in the meanwhile if push notification is sent to them, they either don't receive them at all or receive them very late. The delay varies from an hour to couple of days sometimes. This is completely unacceptable to our clients. On my server logs, I found that push notification is pushed immediately from our server to APNS server. Now APNS makes the delay in sending the notification to apple devices. Once the device starts receiving the notifications, then subsequent messages are sent immediately. Can someone here please help us or guide us why APNS might be doing so. Does APNS mark any device or application as inactive if it is in idle mode for some time and then it checks at regular interval if app has become active? Is there a way to solve this issue from our end so that the push notification is sent immediately to the apple devices without any delay. The apple devices on which we are facing issues ranges from iPhone-6 to iPhone-X and iOS version from iOS-10.x to iOS-11.x. We have not checked this in older versions though as most of our clients have updated their devices to latest iOS versions.
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.
We use push notifications in our app. They work, but there's some variable delivery delay (sometimes ~10seconds, sometimes more than minute).
Does anybody know what to do to minimize those delays?
I know APNS has some delay, but I've never experienced such slow deliveries.
EDIT:
I digged out some time delay between message sent date and push created date.
I have message sent at 12:40:17 (according to QB's admin panel)
and push notification log for the same message says the the push is: "created_at":"2016-05-12T12:40:28Z"
Clearly we have 11 seconds difference between the time message is sent to QB and push notification being sent to APNS from QB
Push notifications are unreliable and cannot be guaranteed that they have been delivered. It all depends on the apple APNS server, that said, usually when I send a push notification I get the result in under a few seconds.
They are not reliable! ****There is no guarantee that push notifications will actually be delivered, even if the APNS server accepted them****.
As far as your server is concerned, push notifications are fire-and-forget; there is no way to find out what the status of a notification is after you’ve sent it to APNS. The delivery time may also vary, from seconds up to half an hour.
Also, the user’s iPhone may not be able to receive push notifications all the time. They could be on a WiFi network that does not allow connections to be made to APNS because the required ports are blocked. Or the phone could be turned off.
APNS will try to deliver the last notification it received for that device when it comes back online, but it will only try for a limited time. Once it times out, the push notification will be lost forever!
For what it's worth I am running into this issue too with Quickblox. The push notifications, a critical part of the communication flow, are delayed by up to a minute or so. I use push all the time in enterprise apps and yes, they should not be considered reliable, but in practice APNS communications are remarkably reliable and near instantaneous in my experience. It seems like Quickblox is queuing (throttling?) notification requests, my guess is to conserve bandwidth - aren't they based in Russia? It's spoiling what would otherwise be a great product.
Our app uses APNS to receive Push Notifications. However, our client claims that some of their devices were not receiving notifications and argues to they 'must' make sure the notifications to be delivered 100%. But I have read somewhere that APNS is not 100% reliable and there should be cases which the notifications are not delivered.
I'm currently panic at how we could make sure APNS to received anytime. I have read that a case which may APNS not delivered (device may offline). But our test showing that even the device is online (Wifi or 3G), sometimes APNS were not delivered.
Is there any specific case which may APNS will not delivered? Or is there anything we (developers) can do with codes to make sure to receive all notifications? What I have done in the code is just registering the app to remote notification and write didRegisterForRemoteNotificationsWithDeviceToken, then throw the device token to our server.
Any help would be appreciated, for our client almost kill us if ALL of their devices not receiving APNS!
APNS is based on Apple Servers, and Apple doesn't give any guarantee on successful message delivery.
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.
Notification shows up only when the app is backgrounded or killed.
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).
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
We're facing the same problem. As everybody said, APNS is a best effort service so you can't be sure every notification will be delivered, but what you can do is to be sure of which ones have been received. This is what we're about to do. We register in our backend each notification que ship and the mobile app reports back each notification it receives. Then we set a maximum time of waiting for a notification to be received, if we don't receive the report back we try again.
I hope it might be helpful to someone (even 2 years later)
It says it quite clearly in the Apple Docs that it is not 100% gauranteed and nor should it be used as so. Its sent with "best effort".
As per Apple's guidelines, APNS is not 100% reliable service which means your app may not get push notifications from Apple servers due to some of the following reasons:
Device is offline
Your app is in the foreground state, you need to manage the push notification.
Note: Apple rejects apps which make compulsion to use notification services. (I have faced it in one of my App)
For more information, you can look into this answer
https://stackoverflow.com/a/25830955/3278326
I want to add a fire alarm function to my app. I think the push notification may be the best choice. But if there is much delay, like over 10 mins, it would be meaningless for fire alarm.
So how much delay for push notification, assuming the device is online?
Push notifications are unreliable and cannot be guaranteed that they have been delivered. It all depends on the apple APNS server, that said, usually when I send a push notification I get the result in under a few seconds.
More Information:
They are not reliable! There is no guarantee that push notifications will actually be delivered, even if the APNS server accepted them.
As far as your server is concerned, push notifications are fire-and-forget; there is no way to find out what the status of a notification is after you’ve sent it to APNS. The delivery time may also vary, from seconds up to half an hour.
Also, the user’s iPhone may not be able to receive push notifications all the time. They could be on a WiFi network that does not allow connections to be made to APNS because the required ports are blocked. Or the phone could be turned off.
APNS will try to deliver the last notification it received for that device when it comes back online, but it will only try for a limited time. Once it times out, the push notification will be lost forever!
Source: http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12