I am using push notification in an app. Everything is going fine.
Sometimes message sent from server but in app side it does not receive.
In this situation I
The Feedback Service
The Apple Push Notification Service includes a feedback service to give you information about failed push notifications. When a push notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device’s token to its list. Push notifications that expire before being delivered are not considered a failed delivery and don’t impact the feedback service. By using this information to stop sending push notifications that will fail to be delivered, you reduce unnecessary message overhead and improve overall system performance.
Query the feedback service daily to get the list of device tokens. Use the timestamp to verify that the device tokens haven’t been reregistered since the feedback entry was generated. For each device that has not been reregistered, stop sending notifications. APNs monitors providers for their diligence in checking the feedback service and refraining from sending push notifications to nonexistent applications on devices.
1. If you are asking about notifications not delivered on a device which has application installed on the device and just because of notification getting expired before it is delivered or something else, notifications are not delivererd.
Then the answer is
It does not provide support where in you can check if the Notifications is expired and not delivered on a valid device:
any option to know if apple app get the push notification?
Refer to Moshe's answer in above link. I am including his answer here so that it is useful to everyone in future even in case the link becomes dead.
The short answer, you can't, since APNS is one way. However, since an app can execute arbitrary code upon receipt of a notification, you can use this to say, send an http request to your own server when the notification is recieved.
2. If you asking of the notifications not delivered as user has uninstalled the application then you can refer to meda's answer in this post.
Hope this helps you and let me know if you have any queries regarding my explanation.
You can get the the delivery report of Push notification, Not from server but from your app, using "Service Extension" and modifying little bit in your Push json. Checkout this link for detailed explanation.
Apple will not tell you the following:
On the other hand, when the user has opted for Push Notifications then your app can handle this but to a certain extent:
Basically, you could add logic in the -didReceiveRemoteNotification:
and -didFinishLaunchingWithOptions:
to contact your server and tell your server that the message was received.
If it wasn't received within a particular time slot then you can resend it.
But as you see, this could lead to a possible scenario of flooding an innocent user with the same push notifications.
In a sense, harassing him to tap your stupid push notification, which in turn may lead him to switch off push notifications for your app entirely but mostly he would delete the app and maybe even give it a low rating?
Serves you right, I'll say.
Anyways, if you go ahead with this, you would need to implement an identification pattern where you insert a unique message identifier
into the payload of the push notification and when your app gets this push notification, it should send this message identifier
back to the server.
Your server should then log that a particular device token returned a message identifier
, which means it received that particular push notification.
Your server can check on a hourly/daily/whateverly basis and resend a particular message to those device tokens that have not reported back with the relative message identifier
.
Again, this means your server might need to work OT sometimes.
There are other issues with this whole approach:
You can circumvent the last 3 scenarios by having even more logic in your app that queues the message id's that are to be sent to the server and removes it only when the server responds successfully.
So you see, too much work, server-side + client-side.
Plus it's a massive performance degrader on the server-side when dealing with a good volume of users as well as lowering the performance of your app by a wee bit.