How to Know Push Notification Delivery Status

Firebase Cloud Messaging - Identify delivery status for a particular push notification message

If someone turned off push notification – you can check it with code

Swift ios check if remote push notifications are enabled in ios9 and ios10

Android app - detect if app push notification is off

But user can be offline, or APNs / Firebase service – can get some problems and your notification will be drop. You can check delivery status with some code in iOS and Android applications.

If you need check, delivery status for some push you can make push notification extension (in iOS). For send status about delivered notification in your API. More info about push notification extension.

https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension

It can be helpful

https://developer.apple.com/documentation/usernotifications

https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications

https://firebase.google.com/docs/cloud-messaging/understand-delivery
https://firebase.google.com/docs/cloud-messaging/android/receive#handling_messages About handling messages in Android (you can send status delivered too)

I hope this answer will help with your problem.

UPD:

https://firebase.google.com/docs/cloud-messaging/understand-delivery

Received (available only on Android devices) — The data message or
notification message has been received by the app. This data is
available when the receiving Android device has FCM SDK 18.0.1 or
higher installed.

How to know Push Notification delivery status

Nopes, push notifications are fire-and-forget.

Apple will not tell you the following:

Will not tell whether the message was sent successfully or not
Will not tell if the user has opted out of Push Notifications
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:

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
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
User received push notification but taps it at a later time
- might get same push notification multiple times (very irritating)
User received push notification but taps it when there is no internet connectivity
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.

Firebase push notification delivery report

In my case that was because of overriding handleIntent function in FirebaseMessagingService. So with removing this function from service the problem fixed.

How to Know whether Push Notification Delivered or not to an iOS app using Pushsharp?

APNS will not provide any Feedback for Push Notification. So we need to use a Silent Push Notification by make use of content-available property in aps dictionary. As we require a Normal Notification, we must put alert, sound, or badge payload in the aps dictionary. So that The Push Notification will visible to the User. As we are using content-available property in payload, iOS wakes up our app in the background so that we can send Delivery Report to our Web Server.

Sample Payload:

    {
        "aps" : {
            "alert" : "Sample Push Notification.",
            "badge" : 2,
            "sound" : "sound.aiff"
            "content-available" : "1"
        }
    }