APNS Feedback Service Discontinuation

We do not provide immediate feedback when a user has uninstalled an application to limit exposure of the state of a user's device. What application experience are you trying to improve after the user has deleted an application? Is there action you want to take on uninstall, or is this information that you want to use in aggregate and not specific to a particular user?

I believe the HTTP2 API provides the same capability, but asynchronously in response to each request instead of having to use the feedback service. So no capabilities are lost in the switch from the binary API to the HTTP2 API, but the implementation is different.

However we have a similar need as the original author here. We would like to know when notifications may be leading users to uninstall an application. For example, we may want to test the delivery of a promotion via a push notification to a small group of people, and then make sure that it doesn't lead to a high uninstall rate before delivering it to a larger group of people.

Or another use-case of detecting uninstalled applications would be to support failover to another messaging channel such as email or SMS.

Or another use-case of detecting uninstalled applications would be to support failover to another messaging channel such as email or SMS.

This is exactly our use case. We do not send notifications for marketing purposes but in support of reminding users of tasks to perform from an enterprise system.

In the event they uninstall the app but still maintain the account on our system. We fall back to other forms of notification, SMS and then email.

I came to this thread while exploring why we are not getting 410 status codes from the HTTP2 service. We have apps uninstalled and always receive 200 status code, though no push was delivered. Tested on push tokens of uninstalled apps from weeks ago. I thought we would just implement the feedback service to work around this issue.

But since that is being discontinued, our root cause reason for not wanting it discontinued or a provide better option is that HTTP2 does not work as promised.

What application experience are you trying to improve after the user has
deleted an application? Is there action you want to take on uninstall,
or is this information that you want to use in aggregate and not
specific to a particular user?

We have a medical communication application with some similar concerns / findings as others in this thread. Our use case is as follows:

1. User1 installs application on their personal phone (BYOD scenario)

2. User1 logs in to application and goes "on call" for certain types of notifications

3. System send notifications to User1. Success. Other users can see that User1 was sent a notification.

4. User1 uninstalls application. NOTE: we have no indication of state change on our server side when the user uninstalls. They still show up in our system with a device ID and "on call".

5. Wait 24-48 hours.

6. Today - we check the APNS feedback service every night. We receive notification from the feedback service that User1's device ID is invalid. We find the user in our system by device ID, and automatically mark them "off call" and clear out their device ID in our system so that we no longer attempt to send push notifications to this invalid device.

7. New patient interactions / assignments happen

8. System attempts to send notifications to User1.

9. Error - To the rest of the patient care team, it looks like User1 was sent an alert, but they were not.

Expected Results - at step 8. we receive an error code back from the APNS HTTP/2 interface indicating that the device ID for User1 is no longer valid, and we will trigger logic to clear out the device ID and mark them off call in our system. This will prevent sending push notifications to invalid devices, automatically mark User1 off call in our system, and provide a visual indicator to other users that User1 is not receiving push notifications.

Right now, we don't have a clear answer on how to accomplish this use case. In our testing so far, we never get back an "unregistered" status code from the APNS HTTP/2 interface. We *DO* still see User1 unregistered from the APNS Feedback service, but understand that is going away next month. And, keeping the APNS Feedback service around is undesirable because it would force us to manage APNS certificates with annual expiration instead of just using Keys, which is much nicer.