It's handled when your push service trims out dead tokens, which it needs to do periodically anyway.

Thanks for that info, I somehow overlooked this when rolling my own push provider.

For those still interested: There is a separate feedback service (feedback.push.apple.com) that providers should query periodically. It returns a list of device tokens that are no longer valid for your application.

Reference: http://developer.apple.com/library/ios/#documentation/Networ...

Hmm, while the documentation does say this, in my experience the token never changes, even across app for a given device.

The APNs token is unique to the install of iOS, not the hardware. So if a user moves to new hardware (with a different UDID), and they restore from a backup of their previous device, the token stays the same. Similarly, if a user does a complete restore of an iOS device (same UDID), but sets the existing device up as a new device, a new token is assigned.

I have about a year of data from providing push to ~100K active device tokens. The former scenario, where a user upgrades to a new device and restores from a backup of their old device is really common. The latter almost never happens. So the UDID is marginally useful, in that it allows you to abstract push-enabled iOS systems from iOS devices.

For doing something like user authentication, the APNs token is actually preferable, because it gets transported along with app data when a user upgrades to a new device. I'm guessing that developers use the UDID, because when you register with the system to get the APNs token, the user is prompted to accept or deny push notifications.

Edit: And, yes, tokens aren't specific to an app; there's one per system that all the apps share.