Delivery Report of Sending Remote Push Notifications Using Apns - iOS

How to know Push Notification delivery status

Nopes, push notifications are fire-and-forget.

Apple will not tell you the following:

1. Will not tell whether the message was sent successfully or not
2. Will not tell if the user has opted out of Push Notifications
3. Many other things but anyways...

---

However

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:

1. User received push notification but dismisses it rather than opening your app with it
   
   
   • Your server will assume the user did not see the push notification and will send this push notification again
2. Ghost device tokens
   
   
   • User accepted push notifications at first but later revoked this privilege
   • User uninstalled the app
   • Basically, device tokens that once use to receive push notification but no longer do, most probably due to your message flooding reputation
3. User received push notification but taps it at a later time
   
   
   • might get same push notification multiple times (very irritating)
4. User received push notification but taps it when there is no internet connectivity
5. User received push notification but your server is down, possibly fried \m/

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.

Independent Watchkitapp APNS push notification successful send but notification does not receive in Apple Watch

Finally, I got this successfully. I use node-apn to send from server.

Here are the worth noticing things:

1. create app id of the watchkitapp bundle in Apple Developer page

2. install the latest version of: node-apn,

   "dependencies": {
   "apn": "git+https://github.com/node-apn/node-apn.git#3.0.0",
   [...]
   }

3. should set apns-push-type

notification.pushType
(Required when delivering notifications to devices running iOS 13 and later, or watchOS 6 and later. Ignored on earlier system versions.)

The type of the notification. The value of this header is alert or background. Specify alert when the delivery of your notification displays an alert, plays a sound, or badges your app's icon. Specify background for silent notifications that do not interact with the user.

The value of this header must accurately reflect the contents of your notification's payload. If there is a mismatch, or if the header is missing on required systems, APNs may delay the delivery of the notification or drop it altogether.

Is it possible to get a delivery receipt for a remote Push Notification at the time of delivery?

You can't tell if a push has been delivered.

The feedback service is designed to inform you of devices which have failed to deliver pushes for some time. You should act on the data in there and stop sending pushes to that device. It could take time to get into the feedback service though because it's only really meant to go in there when Apple have deemed that the device has uninstalled your app, or the device is no longer used, or a similar event rather than just the device is out of range at the moment and has no connection to APNS.

Updating a delivered notifications ios 10

Each time you create an updated notification...just use the same identifier. For more see this moment for the WWDC video.

The above answer is for local notifications but you're looking for remote notifications...

Still see the same moment to get the idea...the only difference is that for local notifications you have identifier...for remote notifications you have apns-collapse-id header:

So just give a value to apns-collapse-id and each time you send a new one it will update the previous one. Obviously if the user is in the app then you're out of luck, because they've already received the notification. This would only work if the user hasn't opened the notification yet (nor is in the app). If they have opened it then a new notification is sent.

apns-collapse-id

Multiple notifications with the same collapse identifier are displayed
to the user as a single notification. The value of this key must not
exceed 64 bytes. For more information, see Quality of Service,
Store-and-Forward, and Coalesced Notifications.

From Apple docs:

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. For details on the apns-collapse-id key.

---

*: come together and form one mass whole

---

Related Topics