Does the APNS device token ever change, once created?

Question

Once created does the push notification device token ever change?

Example when the app is updated? or in any other case it can change??

Mauer

Make sure you see this answer as it provides documentation to 4 places where device token changes – Borborygmus

Answer 1

From [Apple Documentation ApplePushService]2

The form of this phase of token trust ensures that only APNs generates the token which it will later honor, and it can assure itself that a token handed to it by a device is the same token that it previously provisioned for that particular device—and only for that device.

If the user restores backup data to a new device or reinstalls the operating system, the device token changes.

Haydeehayden

The current docs have dropped the last sentence. It appears (from another SO question, #2751981) that restoring data will retain the APN tokens but that O.S. installs and "wipes" will reset it (unless they are followed by restoring data to the newly installed operating system). – Kohl

@RobertAltman - I don't think this is the entire story. I've seen a number of registrations in our database from completely different devices with the exact same APNS token. I see in front of me right now an iPad 2, and an iPhone 3GS that have sent us the same token. Can anyone else confirm this behavior? – Cecil

@DougW, this is strange. Are you still any similar issue? Edited the link and posted from the latest docs. – Tissue

The current docs do have that last sentence, they simply moved and reframed it: "The device token is guaranteed to be different, for example, when a user restores a device from a backup, when the user installs your app on a new device, and when the user reinstalls the operating system". Documentation is not static and the concepts will generally stay the same, though the language is often periodically reframed. – Chiffonier

@Cecil That makes sense if the device tokens registered in your DB are being cached within the app (the docs say to not do that). The device itself might change what its token is based on certain events, but if the app is using a cached token instead of fetching the token from the device, it will continue incorrectly registering the wrong/invalidated token in subsequent registrations. I suspect those devices you were looking at all restored from a backup with cached tokens. – Chiffonier

Answer 2

Apple's official documentation is unclear on this point. What I have observed is this: the token is invariant for a given device, application, and domain (production vs. sandbox). I believe that this must remain true in order for the system to work reliably. Consider the situation where an application update triggers a new APN token; if I were using the greatest new Twitter-like app, with notifications enabled, what would happen when I update my app from iTunes? Should I have the expectation that it will continue to be sent notifications even though I have not run the applications since I "sync" the update onto me device? The act of changing the application cannot affect the APN system since the OS can receive notifications on your behalf even though you haven't run the updated app.

To be clear, Apple states "An application should register [with APN servers] every time it launches and give its provider the current token". I wholeheartedly agree; doing so will protect your application from bad assumptions or unusual situations.

One of the answers to Are push notification tokens unique across all apps for a single device? indicates that device tokens are unique per "operating system install"; and that restoring from backup to a device would maintain the token but wiping a device will cause it to get a new token. This would be entirely consistent with Apple's intentions of seamless operation and privacy: wiping a device is severe enough that perhaps it warrants a new association, but a user restoring an image after an OS update would want to preserve their existing notifications. If I recall the recent iOS5 update on my iPad, I restored the most recent backup after upgrading, so this would have maintained my notification token's consistency. [Edit: restoring a backup to a different device will NOT duplicate the token.]

caveat: I do not have definitive knowledge on the subject, just some reasonable experience working with APN (as a third-party developer). As always, it is best to verify your assumptions.

---

Update (June 2012):

I recently had a chance to a> talk to Apple engineers and b> run some real world tests, and I wanted to present the results:

To be complete, when I talk about returning an APN token, I am assuming the context of a single bundle identifier/application.

First, the Apple engineers said that it should not be possible for two devices to return the same APN. Notwithstanding the comments below, I have not been able to identify a circumstance where this fails.

Second, here is the upgrade test sequence and results:

1. Start with iOS4 installed on iPhone4; backup device in iTunes

2. Upgrade to iOS5
   From a previous test, I know that the APN token is now different

3. Restore the backup to the device
   The APN token is now the same as step 1.

4. Reset iOS (clean device)
   The APN Token changes

5. Backup a different phone to iTunes and restore that backup to test device; basically, I'm restoring the "wrong" backup, as if I were switching phones.
   The APN token changes again; further it is distinct and does not match the tokens either the original token or the "cloned" token.

6. Restore the "correct" backup to the device.
   The APN token is now the same as step 1.

7. Lastly, I upgraded the phone to iOS6 (beta2), restored my backup, and re-tested. As expected, the token continued to match the token in step 1.

At this point, I'm pretty confident that APN tokens can't be duplicated between different devices; perhaps this may have happened as a bug in earlier versions of iOS, but I'm confident that iOS5 (and presumably iOS6) are handling APN tokens correctly.

---

Update (August 2012)

I just realized I had not added this: device tokens will change. One of the Apple devs shared with me that tokens do actually expire (after 2 years, I think). For many purposes, this is long enough that can be thought of as invariant.

[I'm not worried if I have to update my test scripts with new tokens every two years, especially since I change phones every year.]

Kohl

so does this mean you can use the token as a way to uniquely identify a user? (which is very practical in apps where one has to 'vote'?). I can imagine the situation: User votes, and the app responds with a random number via the notifications. That number has to be resend to the server in order to make the vote valid. This way voting can not be rigged easily. – Contrastive

also interesting: does the token change when deleting the app, and the re-installing it. Or is this similar to the 'restoring a backup' option – Contrastive

@Contrastive The token won't change as a result of removing and re-installing an app. – Kohl

@Contrastive I wouldn't think that this would be a good form of user identification; since the token is unique per device (as well as per app), a user with multiple devices will have multiple tokens. – Kohl

If the user can only game the system by issuing his vote 2 or 3 times (depending on how many devices he has), I think it's not that bad. I wouldn't know what the alternative is, except for sending sms's to a phonenumber (which can be gamed similarly as you describe). – Contrastive

Apple has a concept of a user identity. This comes into play when validating in-app upgrades or purchases; basically, an app upgrade is "validated" against the purchaser, irrespective of the device. I'm not certain how this could be used, but it's a thought. – Kohl

the apple-id! Yes it would be great if somehow the app could validate the user as well. (and you are right, voting through an in-app purchase would also make it very difficult to game the system) – Contrastive

Could you think of any scenario where the same token would be returned for different devices, as in the recent UDID leak? – Roselynroseman

@Timo Apple engineers told me that the token should NEVER be the same on two different devices. I tested the scenario of backing up a phone and restoring to a different phone, and confirmed the token had changed. At this point I'm satisfied that the devices will not share a token. If it does ever happen, I imagine that Apple would really like to hear about it. – Kohl

@RobertAltman I also got the confirmation from Apple. Nevertheless, there are a lot of duplicates in the leaked data, and I found additional duplicates of those very tokens in my own production database. – Roselynroseman

@Timo Unfortunately, I believe you (but it's not what I wanted to hear). I would encourage you to file a radar bug report with Apple (regarding your data; it's probably best not to file with the leaked data) – Kohl

I know that there was a hacktivation for illegitimate iPhones some years ago. Some joker supplied one key for all jailbroken iPhones. This might be part of the problem. Mainly seeing 3GS-generation devices for the dupes. – Roselynroseman

@RobertAltman side question. I have been thinking about updating my phone every year being a developer, but I have just bought the iPhone 6 plus after upgrading from an iPhone 4, and I bought the phone outright from the apple store. It was quite a deep dig into my pocket. Now apple will release the next iPhone this year, and I'm wondering whether I should make another investment? cont. – Rigger

@RobertAltman cont. Here are my questions to you: 1) did you purchase every device increment from iphone 5 to iphone 5s depiste the changes being very minimal and will you do the same for iPhone 6s assuming again the changes will be very minimal, does it justify the re-investment for that minimal change? 2) Do you buy your phones outright or are you on a yearly phone plan which allows you to change your phone every year? it's either that or you can just afford to buy each increment. I try to stick to a purchase every-second iPhone device released. I hope you can answer my 2/3 questions – Rigger

@Paven I don't actually buy every phone; I typically upgrade when major phone versions are brought out (iPhone 3G, 4, 5, and 6). The simulator is probably the best way of affordably covering "all" devices, but I really haven't found it necessary to test on all physical devices. In fact, one of the biggest problems with the phones is that you can't revert a phone to an older iOS version for testing -- you will need to use the simulator for that. Continued... – Kohl

@Paven I used to buy my phones outright, but for AT&T and Verizon, the cost of cancelling a contract ($350) is less than the extra cost of purchasing the phone off-contract ($+400), so I have been buying them on. T-Mobile allows you to buy the phone in full but pay in installments. Of course, all of this is subject to change, so you should do your research. It's also not bad experimenting with different carriers' phones: having Verizon has allowed me to trouble-shoot situations where the phone stop reporting its location because the user made a phone call. Hope that helps. – Kohl

I wonder about the relationship between certificates and device token. if .p12 certificate expires, then need to change the new certificate. I found a reference "When a new device token is needed, APNs generates one using information contained in the device’s certificate." So isn't a possibility of device token refresh when changing certificates? – Benz

Answer 3

I've just tested it with iOS9 and APN Push token changes if I reinstall an app.

Rayborn

I can confirm this too – Boondocks

Yes, it's changing :( – Avoidance

Yes, it would change – Strasbourg

App re-installRemember that Apple has a vested interest in having push notifications work after phone or operating system upgrades. Consider this: when you upgrade your phone OS, do you need to re-run EVERY application which sends you push notifications? This would be patently unworkable, and Apple works very hard not to have this kind of burden foisted on their customers. Likewise, when upgrading to a new phone, it is not necessary to keep a list of push-notification apps and re-run them all to ensure you receive your notifications. – Kohl

App re-installs are one of the cases where I would expect the token to change. There is no reason to keep the existing token and many security-related reasons to generate a new one. – Kohl

Answer 4

YES, device tokens can change.

Anytime your app receives a token, it should store it. Then, whenever a new token is received (which will happen, eventually), compare the new token to the stored token and, if they are different:

1. Update the device's local storage, (including possibly to nil)
2. Update anything on the device which uses the token to be aware of the new token
3. Update any APIs which are aware of this token to the new token.

As a practical matter, the last step is the most likely to be non-trivial. For example, if you have a service which is sending weather alerts to a device token based on what zip code that device has subscribed to, then you need to pass the old_token and the new_token to said service so it can update delivery.

Ergo, generally speaking 100% of APIs accepting a "device token" must also have some kind of UPDATE facility for that token. To not build for this is to build for mis-delivered and non-delivered notifications.

Kirst

sounds good, but what is I've removed and reinstalled my app? in that scenario the device token I saved under local storage will be deleted – Winterfeed

@Kuf, did you get an answer to that question? I have the same - in the even the app is uninstalled/reinstalled, how would we compare the system token? – Befit

@Befit see this question for more details – Winterfeed

The three "Update" points you talked about, are they responsibilities of iOS, the SDK, or ourselves? – Choosy

Answer 5

Device token does change from iOS 8 and later

Please see text below from Apple website. Registering, Scheduling, and Handling User Notifications

The device token is your key to sending push notifications to your app on a specific device. Device tokens can change, so your app needs to reregister every time it is launched and pass the received token back to your server. If you fail to update the device token, remote notifications might not make their way to the user’s device. Device tokens always change when the user restores backup data to a new device or computer or reinstalls the operating system. When migrating data to a new device or computer, the user must launch your app once before remote notifications can be delivered to that device.

Petitioner

URL is dead! Please fix it. – Sachet

good link – Natheless

Answer 6

I think it is worth mentioning as nobody did it that the token changes after you have called unregisterForRemoteNotifications. When you call registerForRemoteNotifications next time the token is different. I failed to find any confirmation of this in the Apple docs but I witnessed such a behavior myself. Please keep this in mind

Lush

Answer 7

Links quickly become obsolete with apple! so i'm quoting what seems to be quite clear now :

Never cache device tokens in your app; instead, get them from the system when you need them. APNs issues a new device token to your app when certain events happen. The device token is guaranteed to be different, for example, when a user restores a device from a backup, when the user installs your app on a new device, and when the user reinstalls the operating system. Fetching the token, rather than relying on a cache, ensures that you have the current device token needed for your provider to communicate with APNs. When you attempt to fetch a device token but it has not changed, the fetch method returns quickly.

From this guide

Balcom

Answer 8

From - Apple Docs

APNs can issue a new device token for a variety of reasons:

• User installs your app on a new device

• User restores device from a backup

• User reinstalls the operating system

• Other system-defined events

As a result, apps must request the device token at launch time.

Additionally:

_{I M P O R T A N T}

APNs device tokens are of variable length. Do not hard-code their size.

---

From Latest Docs (2023)

Never cache device tokens in local storage. APNs issues a new token when the user restores a device from a backup, when the user installs your app on a new device, and when the user reinstalls the operating system. You get an up-to-date token each time you ask the system to provide the token.

Twoseater

what are these 'Other system-defined events' ? – Minimize

Answer 9

It shouldn't change, unless your app is restored onto a new device (at which point it won't be asked to accept push notifications again, and will simply send you the registered call at which point you should accept the new token).

But Apple doesn't guarantee that it never changes (hence the documentation never mentions it). You better program for the worst and assume it may change one day. Also, sending a token to your server regularly enables you to remove tokens that haven't registered for a while, and have probably deinstalled your app or lost interest a while ago (and the documentation does specify this as wanted behavior!).

Robinett

You are correct: you can't assume the token is permanent; follow the rules of engagement as defined in the APN docs. In fact, Apple devs have told me that the token will change eventually (after something like 2 years). – Kohl

Resurrecting an old discussion, but someone might find it useful: I've spent some time this week working on a self-hosted Parse server, and having testing issues - turns out that every time I refreshed my dev app (as I was making a number of UX changes as well), the token id changed with each software install... so ain't that just too much fun? (sigh) – Incalculable

Answer 10

As reference to Apple push notification stuff

The device token is your key to sending push notifications to your app on a specific device. Device tokens can change, so your app needs to reregister every time it is launched and pass the received token back to your server. If you fail to update the device token, remote notifications might not make their way to the user’s device. Device tokens always change when the user restores backup data to a new device or computer or reinstalls the operating system. When migrating data to a new device or computer, the user must launch your app once before remote notifications can be delivered to that device.

Never cache a device token; always get the token from the system whenever you need it. If your app previously registered for remote notifications, calling the registerForRemoteNotifications method again does not incur any additional overhead, and iOS returns the existing device token to your app delegate immediately. In addition, iOS calls your delegate method any time the device token changes, not just in response to your app registering or re-registering.

Hospitalization

Link in answer is dead - "404 | The page you’re looking for can’t be found.". – Chaunceychaunt

Answer 11

According to this link the device token

The device token included in each request represents the identity of the device receiving the notification. APNs uses device tokens to identify each unique app and device combination. It also uses them to authenticate the routing of remote notifications sent to a device. Each time your app runs on a device, it fetches this token from APNs and forwards it to your provider. Your provider stores the token and uses it when sending notifications to that particular app and device. The token itself is opaque and persistent, changing only when a device’s data and settings are erased. Only APNs can decode and read a device token.

Histochemistry

Answer 12

Yes it can change. Ideally when ever we receive a token via the callback method

• (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken

The app should register / refresh the token on the remote server. This will ensure that the token on the APNS and your server is kept in sync.

As per Apple documentation,

Obtaining and handling an app-specific device token works as follows:

Your app registers with APNs for remote notifications When a new device token is needed, APNs generates one using information contained in the device’s certificate. It encrypts the token using a token key and returns it to the device, as shown in the middle, right-pointing arrow. The system delivers the device token back to your app by calling your application:didRegisterForRemoteNotificationsWithDeviceToken: delegate method. Upon receiving the token, your app (within the delegate method) must forward it to your provider in either binary or hexadecimal format. Your provider cannot send notifications to the device without this token. For details, see Registering to Receive Remote Notifications in Configuring Remote Notification Support.

Tissue

Answer 13

The device token relay on the installation of the app.

It means that if you reinstall the application, it changes; it doesn't metter if you do it from a backup, an iOS upgrade ecc..

The right way to use it, to avoid any problem, is to get the one given on the NSPAppDelegate at each application launch, in the method didRegisterForRemoteNotificationsWithDeviceToken

Crooked