I understand we can add code on iOS client side to detect whether the user has disabled push notification permission, my question it, is it possible to do it in only using APN?
I try the "Feedback Service" first, from Apple Programming Guide:
The Apple Push Notification service includes a feedback service to
give you information about failed remote notifications. When a remote
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. Remote 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 remote
notifications that will fail to be delivered, you reduce unnecessary
message overhead and improve overall system performance.
FeedBack Service payload
So "Feedback Service" essentially give us a token list for failed push notifications. I tried to send push to a device with disabled push notification permission or app uninstalled , however my device token does not appear in this list.
Apple's document also mentions we will get immediate response from APN once we send the push notification:
If you send a notification that is accepted by APNs, nothing is
returned. If you send a notification that is malformed or otherwise
unintelligible, APNs returns an error-response packet and closes the
connection. Any notifications that you sent after the malformed
notification using the same connection are discarded, and must be
resent. Figure A-2 shows the format of the error-response packet.
However, it seems like the returned status stays the same no matter what I do: enable/disable push notification permission or even uninstall the app...
I fact, my hypothesis is that even the user has disabled the push notification, APN will still see it as a successful delivery, but iOS just simply don't show it. None of them response code from APN seem to be related to the disabled push notification.
I am wondering if there is a way to do it with APN? Thank you!
Reference: Apple Doc:https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/BinaryProviderAPI.html#//apple_ref/doc/uid/TP40008194-CH13-SW1
Related
I googled but not able find my desired solution. My Questions are following related to push notification.
What if registered device turned off its push notification and server broadcast notification. Is notification place in waiting list (e.g when device turned on notification it gets notification) ? or Reject ? or Server keep sending ?
If server keep sending how to tackle this situation, I mean is there any way that we can find our some client turned off notification then we'll not send notification to APNS?
If someone already asked then kindly reference those question instead of down vote.
Looking for answer. Thanks
APNS docs here: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
Your server - what Apple calls the provider - maintains a list of device tokens that have registered for your notifications.
When a device turns off push notifications, you should remove its device token from your list.
So far as I know, if you attempt to push to a device that has turned off push notifications, your provider will receive an error, and the push notification will not be queued. It should be easy enough to test using a device.
Push notification has some drawback eg:
1. It doesn't revert if its delivered or not
2. If device was off the push notification arrives in bunch. (I don't need the old push notifications if device was off)
For the purposes of displaying messages to users who do not currently have your app open, there is no alternative to Push Notifications.
However, each of the drawbacks you mention does have a solution.
Determining delivery status
There are 2 possible reasons a notification will not be immediately delivered.
The device has uninstalled your app
If the device has uninstalled your app or opted-out of notifications, Apple will return the failed recipient device token through their Feedback Service protocol. In the newest HTTP/2 version of APNS, the failed recipient token will be returned as a response to your HTTP/2 connection.
The device is turned off or does not have a network connection.
Apple will attempt to deliver your most recent notification to the device when the device comes back online. If determining delivery status is essential to you, then you can supply the Content-Available flag and have your application report any successful deliveries of notifications.
Managing notifications when devices are turned off
By default, Apple will deliver only the one most recent notification per application when a device is turned on. This prevents the possibility of a user receiving a deluge of notifications from any single app when they turn on their device.
You can also prevent Apple from delivering old notifications by setting a TTL value. If the TTL expires before Apple is able to successfully send the notification to a device, the notification will be discarded.
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 have to know which message is missing to deliver(app did not receive).
Is there any way to know from server side which message is received by app and which are not?
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.
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
Nope.
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.
The documentation specifically states that the feedback service will report devices where the app has been uninstalled and won't report devices if the push merely expired.
My question is, will it report devices that have the app installed but the app called unregisterForRemoteNotifications (e.g. the user "signed out" of the app)?
Documentation:
APNs has a feedback service that maintains a per-application list of devices for which there were failed-delivery attempts (that is, APNs was unable to deliver a push notification to an application on a device). Periodically, the provider should connect with the feedback service to see what devices have persistent failures so that it can refrain from sending push notifications to them.
Source: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html#//apple_ref/doc/uid/TP40008194-CH1-SW14
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.
Source: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3
My answer is YES, APNS does have this service in place along with its feedback service, mainly because the server triggering the push service will have to be notified back to stop sending push notification to the devices which have manually opted out of push notification service.
And since there is no way this information can reach back to the server directly except through APNS, APNS manages to hold this information to provide it back to the server.
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