I have an iOS app that receives notification from APNS. If my user deletes the app there is no way for the backend to know the app is not installed on a certain device(device token). In this case what error code will be generated when trying to push via APNS, so that i can remove the entry from the database?
There is a Provider (Your backend server) API introduced by Apple in WWDC-2015 & enhanced in 2016 to give more valuable feedback to the server about the push notification. Here is a transcript to that WWDC session.
From the transcript: "If a device token has been removed, you will get an HTTP/2 response with status 410, or "removed."
It will have a time stamp in payload indicating when APNS last learned that the device token has been removed."
APNS Server Response Codes
200 Success
400 Bad request
403 There was an error with the certificate or with the provider
authentication token.
405 The request used a bad :method value. Only POST requests are
supported.
410 The device token is no longer active for the topic.
413 The notification payload was too large.
429 The server received too many requests for the same device token.
500 Internal server error
503 The server is shutting down and unavailable.
Now what I cannot confirm to you is that if iOS removes the device token if app is removed or if notification setting is turned off from App settings without deleting app.
"410 does mean the app was uninstalled. The token will remain active if the user disables notification alerts in the app settings. The device will still receive the notification, even if no alert is shown to the user. The server will not know if the user has turned off notification alerts. Only the app knows this."
Thanks to Marcus Adams for clartfying this doubt.
Here goes the Apple Developer Guide!!!
If required, Here is a Paid SDK that can help you with uninstallation tracking.
Related
we are planning to move to the new Token-Based Connection to APNs to send notifications.
Apple Document.
This supports sending notifications to multi apps under the same team id and irrespective of environment stage/prod.
But weirdly when try to send notif to device token of production app it's working.
whereas when I tried to send notif to stage app device token it failed with error 400 BadDeviceToken.
From the documentation, it mentions the following:
For security, APNs requires you to refresh your token regularly. Refresh your token no more than once every 20 minutes and no less than once every 60 minutes. APNs rejects any request whose token contains a timestamp that is more than one hour old. Similarly, APNs reports an error if you recreate your tokens more than once every 20 minutes.
Are you refreshing your development token regularly? If yes, then try deleting the app from the device and reinstalling it from Xcode as mentioned in this LINK.
Hope this helps fix your issue.
Regards,
AJ
I was trying out new GCM feature to send notifications to iOS devices. Everything worked very smooth except the feedback message. I assume after GCM sends message through APNS, GCM also calls feedback service of APNS to get the invalid tokens. Next time when we use the same device token to GCM, it should respond with error message. I tried several times after uninstalling the app, but never received an error message from GCM. Each time it shows success message. What went wrong here?
Note: If you are not familiar with new GCM features, please do not blindly answer to this.
I think the problem here is with the environment. I am using developer certificate to test the notification. APNS may not be giving any details for developer environment. Hope it will work in production.
Updates
Support from Google gave following details.
We did some digging, it seems that is how things are being handled by APNS:
When last sandbox app is removed from the device, device disconnects from APNS sandbox and not able to receive pushes/provide feedback anymore. Thus, APNS feedback doesn't register that the device has been uninstalled.
If you install another push-enabled sandbox app on the device, which would force device connection to APNS again. And we checked that under this circumstance, we get notified that the device has been uninstalled and return NotRegistered to our client.
APNS feedback service is not instantaneous. GCM does poll APNS feedback service but in my experience it was a bit delayed (not sure if it was APNS's delay or GCM's delay).
You should wait for some time and then try to use an old registration token and you should see a "Invalid Registration Token" error.
I couldn't find any decisive answer in Apple's developers area regarding to an issue with unregistered device from APNS.
Assuming a device has unregistered itself from the APSN service, will I get any response in the stream about it unregistered, or the only way I can know about it is the use of Feedback service?
If in fact the feedback service is the only solution, what way is suggested to handle this success -> failure status?
To be more clear, if I don't get any response in the stream, it means it 'might' (use of Apple) reached its destination but then, the feedback indicates it was a failure.
If a device unregistered itself from APNS via your code (i.e. your app's code initiated the un-registration), your app can notify your server to delete the device token (the same way it notifies the server to store the token after registration).
Otherwise, the only way for the server to know that a device token is no longer relevant (due to app being uninstalled from the device or the user disabling push notifications for the app) is by getting the device token in the Feedback Service.
As for responses in the stream, you only get error responses if the message is invalid. It can be invalid due to an invalid token, but an invalid token is a token that was never valid in the current push env (unlike tokens returned in the Feedback Service, which used to be valid, and may be valid again if the app is re-installed).
To be more clear, if I dont get any response in the stream, it means it 'might' (use of Apple) reached its destination but then, the feedback indicates it was a failure.
If Apple didn't send any response in the stream, it means the message is valid, and Apple will try to deliver it to the device. If, when Apple tries to deliver the message, they discover the app was uninstalled from the device, the next call to the Feedback Service would return the device token of that device.
We have a (mostly) successful implementation of push notifications to iOS and Android devices through Azure Notification Hubs.
The problem is that some of the iOS devices are apparently never receiving notifications that are sent by Azure Notification Hubs.
We use templates and tags to direct the messages to the appropriate devices. The tags are interest topics, and never user-specific, so we're expecting one notification for a tag to be pushed to all devices subscribed to that tag.
The Android devices seem to receive their notifications flawlessly, but the iOS devices are not consistent. Most of them work. A couple do not.
We are well aware that push notifications are delivered with best effort and have no guarantee of reliability, but our limited testing has revealed more devices which consistently fail to receive push notifications than seems unreasonable (more than two failures from about a dozen devices).
Here's the setup:
We have a simple C# routine in the back end which connects to Azure Notification Hubs and sends notifications to Azure:
var outcome = await hub.SendTemplateNotificationAsync(properties, tag);
We have used the GetAllRegistrationsAsync method to make sure that every device we are checking has successfully registered and is using the correct template. Every device is registered, all the templates are correct.
We are not in "test mode"; the enableTestSend parameter of NotificationHubClient.CreateClientFromConnectionString is set to False.
Troubleshooting:
When we send the notification out, most devices receive the notification and, in the specific case we're testing, update the badge counter with the correct number.
However, a couple of devices do not seem to get the notification. One of the devices did get the notification after we rebooted the device, but after that it stopped.
Using the above mentioned GetAllRegistrationsAsync method, we have verified that the problem devices are correctly registered on Azure and have the correct tags and templates.
We were able to determine the device tokens of the problem devices from the Azure registrations. We used a PHP script which communicates directly with APNS to send a notification just to the problem devices using their device tokens. Every time, the device receives this direct-send notification. It's only the notifications from Azure which are unreliable.
When we examine the Azure Notification Hub Monitor page, we see these metrics for the past 24 hours:
967 APNS Successful Notifications
3 APNS Bad Channel Errors
2 APNS Expired Channel Errors
4 APNS Errors
... and no other errors reported for APNS or for Azure in general. The failure rate we're seeing should have produced an error count over 20.
We have not been able to determine which device tokens were responsible for the errors; is there a way to get this information from Azure?
We're at a loss to explain why we can send notifications directly to these devices over APNS itself, but not through Azure, and why it is that Azure doesn't report more errors than it does.
Any suggestions or insights?
It's quite possible that you have some sandbox device tokens in your database (I'm not sure if the device tokens are stored in your server or in Azure Notification Hub). When trying to send a notification with a sandbox device token to the production push environment, an InvalidToken error is returned by Apple, and the connection is closed.
Very often, by the time the server that sends push notifications to Apple's APN server gets the error response, it has already sent many more notifications (possibly with valid tokens), and all of which are discarded by Apple. At this point, new notifications are accepted by Apple only after a new connection with APNS is established, so messages that were sent after the invalid token to the old connection need to be resent. It is possible Azure don't handle this resending correctly.
As you said, the Azure Notification Hub Monitor page shows a few errors. I suspect that 3 APNS Bad Channel Errors means invalid device tokens. I don't know how many invalid device tokens you actually have in the DB, but even one can cause many notifications with valid tokens not to be accepted by Apple.
The best solution is to test all the device tokens in the DB and figure out the ones that are invalid and delete them.
I'm developing an iOS app that enables the user to observe technical devices and be notified if there are problems.
What I know so far:
My app requests a token from the APNs.
My app sends this token to my server.
My server notifies the APNs in case of an event.
The APNs pushes a message onto the device.
What I want to know:
I read the token may change, therefor I need to request it on every app launch. Is this true?
If I get a new token from time to time I have to register at my server from time to time to make sure it uses the current token. Do I have to store and manually send the old token with the new one if the token changes to allow my server to delete the old one?
How can I detect that a user removed the app to remove his device on the server?
Highest priority in my case is for the server to know which devices are registered with the service. Old devices (old tokens that is) need to be removed immediately.
Thanks for your help.
You should register for the remote notification on every app launch and send the token to your server.
To check if the user removed the app or disabled notifications you have to check the feedback service. Look for it on this page:
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/BinaryProviderAPI.html#//apple_ref/doc/uid/TP40008194-CH13-SW1
Note: APNs monitors providers for their diligence in checking the feedback service and refraining from sending push notifications to nonexistent applications on devices.