iOS6 UDID - What advantages does identifierForVendor have over identifierForAdvertising?

Apple is changing their privacy settings for iOS6 and deprecating device UUIDs (UDIDs). According to a WWDC presentation and the docs there are two replacements for the UDIDs, both in the UIDevice class:

-identifierForVendor

• ID that is identical between apps from the same developer.
• Erased with removal of the last app for that Team ID.
• Backed up.

-identifierForAdvertising

• Unique to the device.
• Available to all applications; used for advertising — iAd has converted from UDID for iOS 6 and later.
• Reset with "Erase All Content & Settings".
• Backed up.

It seems to me that -identifierForVendor is inferior to -identifierForAdvertising since it would get reset on last uninstall of an app from a vendor and by "erase all contents & settings".

What advantages does -identifierForVendor have over -identifierForAdvertising?

Important Note:

Apple just released iOS 6.0 and the NDA has been lifted.

For developers who preemptively included code that referenced

[[UIDevice currentDevice] identifierForAdvertising]

this method has NOT been included on iOS 6. If you use the above method, your app will (most likely) crash and be rejected!

Instead, Apple has created a new class ASIdentifierManager , which includes the method advertisingIdentifier. Here's the apple docs on it:

Users can limit the use of ad tracking on their phone. See this article on the opt-out mechanism under Settings > General > About > Advertising.

The new ASIdentifierManager class has a property advertisingTrackingEnabled, which returns true or false depending if the user has limited ad tracking. Even though the device's advertising identifier is returned by the advertisingIdentifier property regardless of opt-out, you aren't supposed to use the identifier if the user has opted-out.

So the advantage of identifierForVendor is that you'll always have access to and the right to use this id for the phone regardless of user's opt-in or opt-out for advertising tracking.

I suspect that Apple will simply reject your app if you use identifierForAdvertising for anything that is not advertising-related (i.e., if you send the identifierForAdvertising to your own servers even though you're not an advertising network or if you send the identifierForAdvertising in the same request with other data that could potentially identify an individual).

If my suspicion is correct, the advantage of identifierForVendor over identifierForAdvertising is that it won't get your app rejected.

They are two different ids meant for two different purposes. I would think that the identifierForVendor would be the one to use to do things that require the app linking to a specific user / device such as provide push notifications and updating the user's app data serverside (like their score or whatever other data is being stored for them).
The identifierForAdvertising should be used for things such as targeted advertising and also to check the effectiveness of a particular ad campaign (check to see which devices installed apps due to a particular ad).

Use the VendorID. This is a very enlightening article http://www.doubleencore.com/2013/04/unique-identifiers/

To create a uniqueString based on unique identifier of device in iOS 6:

#import <AdSupport/ASIdentifierManager.h>

NSString *uniqueString = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];
NSLog(@"uniqueString: %@", uniqueString);

Those APIs are so badly designed, that clearly says - Apple does not want us to identify user devices.

Just look at the identifierForVendor description.

It is erased if the user erases all apps from the same vendor. :( It is not reliable - can return nil (documentation advices to "wait" for some time if this happens. :(

They did not use obvious solution, which works anytime and does not rely on installs/removes - return SHA-1 (or any other hash) of internal hardware device id concatenated with Team ID.

identifierForAdvertising is probably superior in terms of tracking but might be subject to present or future opt-out by the user. On the other hand identifierForVendor is not as likely to be subject of the user.

The important thing to know is that the backup of the identifierForVendor can only be restored to the same device. If the backup is restored to a difference device the identifier is cleared.

User can change identifierForAdvertising any time in Settings, identifierForVendor changes after reinstall app, if no more apps on device from this vendor.

Here is alternative and the best solution for get or persistent, cross-install Device Identifier:

description: https://blog.onliquid.com/persistent-device-unique-identifier-ios-keychain/

code: https://gist.github.com/miguelcma/e8f291e54b025815ca46