We are using Amazon SNS as a solution to deliver notifications to 4 of our mobile app's - for each app we have both a GCM as APNS app created in SNS. We've enabled the delivery status loggin for each app both on GCM as APNS (100%). And for all these app's we have received successfull and failure requests in cloudwatch, on top of this we've created a monitoring solution that is querying on the correlated cloudwatch logs.
A few weeks back we noticed that we where missing the delivery logging for all Apple applications - from a certain date no logs where received. We've enabled it again, received logs and now a few weeks later it's disabled again.
Initially we thought the "Apple" applications lost their Delivery Tracking options with renewing the yearly certificate. But we did a test (re-upload the cert) and that did not adapt the delivery failure tracking.
We did a query on CloudTrail on the event "SetPlatformApplicationAttributes" but no events popped up - besides our tests.
At this point in time we have no clue why it keeps getting disabled.
Are we missing some critical info? Is it normal that for Apple apps the delivery tracking is disabled after x-amount of time? What are best-practices for setting this up?
Related
I am currently building a laravel provider service to send push notifications to IOS devices. I have followed this tutorial for creating a sample app which is able to receive notifications.
On my server side, I used this package to handle push notifications.
During testing, the app manages to receive push notifications when the device is connected to wifi/4G, during foreground/background/inactive modes. However if I send the push notification to the app when its offline, on connecting the device back to the internet I do not receive any notifications.
According to the apple documentation, the APNS service stores any notification which is sent when the device is offline and delivers it to the client after connection is re-established. It is supposed to dispose of any notifications if the device stays offline for a long time (duration not exactly specified). However I am keeping the device offline for only a minute before going online. Can anyone please suggest a solution?
Thanks to Brandon I managed to know what the problem actually was. The next challenge I faced was how to integrate the expiry period for the notification in the message payload using the davibennum/laravel-push-notification package. Since there was no documentation regarding this, I had to go through the source code to find out how to define the expiry period. Turns out the expiry time can be set simply by defining it like this in the message payload:
'expire' => Carbon::now()->addDays(30)
Basically you are passing a date time instance, which will then be transformed to the apns-expiration header of the request.
I'm trying to detect uninstalls of our iOS app.
I read this document which gives some useful information. However, how can I understand from the error codes returned whether the user uninstalled versus disabled push notifications/has no connectivity?
I think you'll want to use the Feedback Service. When a user deletes an app, the service provider should ideally stop sending notifications to that device. But Apple does not notify the service that "this device is not using your app, dont send notifications". Technically, a device which has uninstalled your app will not make it onto this list until the next time a push notification goes to the device. So you need to poll for this info using the Feedback Service.
Periodically, you will need to hit Apple Notification servers asking it to give you IDs that have deleted your app. Once you get them you mark them in your DB as deleted thereby not sending any more notifications. This Feedback Service will tell devices that have been unregistered (app uninstalled). The part I'm not sure about is whether a user who has turned off push notifications in settings will register the same. I believe they will not show up in the feed from the Feedback Service. I am certain, however, that users who are offline and the push notification is not delivered will not be included in the list.
It would be a simple test in your dev region to try the app, disable push notifications for the app, and then see if the device shows up in the feed.
Take a look at Apple's documentation
From Apple Documentation -
Apple Push Notification Service includes a feedback service that APNs
continually updates with a per-application list of devices for which
there were failed-delivery attempts. The devices are identified by
device tokens encoded in binary format. Providers should periodically
query the feedback service to get the list of device tokens for their
applications, each of which is identified by its topic. Then, after
verifying that the application hasn’t recently been re-registered on
the identified devices, a provider should stop sending notifications
to these devices.
Access to the feedback service takes place through a binary interface
similar to that used for sending push notifications. You access the
production feedback service via feedback.push.apple.com, port 2196;
you access the sandbox feedback service via
feedback.sandbox.push.apple.com, port 2196. As with the binary
interface for push notifications, you must use TLS (or SSL) to
establish a secured communications channel. The SSL certificate
required for these connections is the same one that is provisioned for
sending notifications. To establish a trusted provider identity, you
should present this certificate to APNs at connection time using
peer-to-peer authentication.
Make sure you also read up on - Issues with Feedback Service
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 think I had once seen a way to tell the Apple Push Notification Service to re-send notifications that were unsuccessfully delivered on their first attempt. Is there a way to do this and can you point me to some information regarding this?
My goal is to send a notification to 100 people and if 10 of them fail to be delivered, have those 10 failures retry.
Unfortunately, as far as I know, no such functionality exists directly. You can check that the notification time to live is long enough, go with a persistent notification solution (Urban Airship), or do your own delivery verification and redelivery through some back end service of your own which would work with Apple's feedback service.
If a delivery failed (APNS connection is lost), APNS would attempt to deliver only the latest notification when the connection to APNS is re-established. Your other notifications would not be delivered if this is the case. If you are looking for something persistent, look at Urban Airship and similar services (Pusher may be another, though I have not used it) that offer functionality similar to an e-mail inbox for various mobile platforms including iOS.
If you're seeing issues with the latest notification not making it through, you might want to check that the TTL is not too short on that notification. That's all that comes to mind.
I implemented push notification in my app.
It is working fine.
Now the problem is even after i deleted my app from device it is getting the push notifications.
So is there any way to unregister the app from push notification when it is deleted from the device.
Hoping for your help.
Thanks in advance.
In Apple push notification there is something called - Feedback Service. So when a user deletes an app, the service provider should ideally stop sending notifications to that device. But Apple does not notify the service that "this device is not using your app, dont send notifications". So instead you need to poll for this info.
Every day you might need to hit Apple Notification servers asking it to give you device Ids who have deleted your app. Once you get them you mark them in your DB as deleted thereby not sending any more notifications. Hope this is what you wanted.
From Apple Documentation -
... Apple Push Notification Service includes a feedback
service that APNs continually updates with a per-application list of
devices for which there were failed-delivery attempts. The devices are
identified by device tokens encoded in binary format. Providers should
periodically query the feedback service to get the list of device
tokens for their applications, each of which is identified by its
topic. Then, after verifying that the application hasn’t recently been
re-registered on the identified devices, a provider should stop
sending notifications to these devices.
Access to the feedback service takes place through a binary interface
similar to that used for sending push notifications. You access the
production feedback service via feedback.push.apple.com, port 2196;
you access the sandbox feedback service via
feedback.sandbox.push.apple.com, port 2196. As with the binary
interface for push notifications, you must use TLS (or SSL) to
establish a secured communications channel. The SSL certificate
required for these connections is the same one that is provisioned for
sending notifications. To establish a trusted provider identity, you
should present this certificate to APNs at connection time using
peer-to-peer authentication.
Be sure to checkout - Issues with Feedback Service
Having not seen this answer so far, there is a small note in the Apple "Troubleshooting Push Notifications" document.
In short, if you delete the last push enabled app, the persistent connection from the device to Apples push server is broken before the server is told that the app has been deleted.
Solution: keep at least one push enabled app on your device.
There is the explanation from the document:
Issues with Using the Feedback Service
If you remove your app from your device or computer and then send a push notification to it, you would expect to have the device token rejected, and the invalidated device token should appear on the feedback service. However, if this was the last push-enabled app on the device or computer, it will not show up in the feedback service. This is because deleting the last app tears down the persistent connection to the push service before the notice of the deletion can be sent.
You can work around this by leaving at least one push-enabled app on the device or computer in order to keep the persistent connection up. To keep the persistent connection to the production environment up, just install any free push-enabled app from the App Store and you should then be able to delete your app and see it appear in the feedback service.
Recall that each push environment has its own persistent connection. So to keep the persistent connection to the sandbox environment up, install another development push-enabled app."