APNS Push Token Management

From the APNS documentation, an error with error coded 410 will be thrown if a push token is no longer valid.

However, Our company is seeing cases where stale push tokens (i.e. tokens that haven’t received any notifications in over 1 year) aren’t getting a 410 error back from APNS. Will APNS throw a 410 error for stale push tokens? What are the conditions under which a 410 error code will be returned?
On the HTTP/2 interface, you will see a 410 error some time after the system has determined that the app has been uninstalled from the device.

How this works though, is, when an app is deleted from a device, the device token is not invalidated immediately.
To avoid developers from detecting and tracking user behavior around installations and uninstallations, APNs invalidates tokens on a sliding schedule. This schedule is not documented, and can change at any time. This is for protecting the users’ privacy, and is by design.

The schedule gets more complicated by the fact that a token is considered invalid (internally) only after a notification is sent to the app, and received by the device once after the app is deleted.
If you have not sent a push to a token for a year, the system may not have the token flagged as invalid until the push after the deletion is sent - and then still wait for the system to decide to report back the 410 status some undefined time after the invalidation takes place.

Either way, the token will eventually start returning 410. It is acceptable to send pushes to the inactive token until you receive the first 410 status. You can send notifications to that token without harm until you receive a 410 error, and after that you can safely remove the token from your list of available device tokens.

If you know for a fact that the token is no longer valid, you can of course delete it from your database at will.

APNS Push Token Management