[benjamincburns]

> On iOS when a remote push notification is received it there is not indication sent to the application at all.

I'm not well versed in push notifications, but I thought this was part of the value that a company like Urban Airship would provide?

[Groxx]

Only if you use their inbox-like thing, which will still not tell you deliverable rate, it just ensures the recipient can see a list of all attempts.

The actual push notification itself is entirely untrackable unless the recipient actually taps on it, or it is received while your app is running. IIRC you can read out the application's badge number, but that only shows you what the most-recently-received notification was (if it set a badge value), it implies nothing about any intermediate ones. There is no way to list the notifications, nor count them. You can do this with local ones you generated yourself, but not ones pushed to the device.

While someone is actively in your app, you do get a method called that gives you the notification as it arrives - which is handy, because the system entirely mutes it (doesn't go into the notification center, doesn't appear at the top of the screen). You can do that to do a negative tracking system ("they didn't receive this, don't count it in the stats"), or to show it yourself.

[rkoz]

The usual approach is to track acks or callbacks driven via user actions on the server-side. Adding a "guaranteed delivery" QoS will involve queuing, waiting and retrying on non-ack timers - and do so without abusing users' trust in your app.

[rubyrescue]

no it's a limitation of iOS - which you could argue is by design. the app is just not notified, no matter if it's urban airship or your_custom_app

[sumukh1]

Regardless, the application has to be opened to get information about click through/context.

The push notification can have a payload that your app uses when the app is opened via the notification.