How Apple’s UDID Deprecation Affects You

March 27th, 2012 § 0 comments § permalink

Last August, the iOS developer community discovered a small change with potentially large implications that came with the introduction of iOS 5.0: the deprecation of the UDID. The UDID is a highly used unique identifier for each iOS device; somewhat like a social security number for your phone or tablet.

UDIDs are widely used in the context of creating and distributing ad-hoc, beta builds. However, there have been a number of security and privacy concerns raised when it was found that this identifier was being used for many other purposes.

To address these concerns Apple has given a new alternative, the UUID, and as of late has been urging more and more developers to expedite the replacement of the UDID in their apps. Some reports indicate that Apple is starting to actually reject apps that reference UDIDs.

From the iOS 5.0 release notes:

Deprecated in iOS 5.0

uniqueIdentifier

An alphanumeric string unique to each device based on various hardware details. (read-only) (Deprecated in iOS 5.0. Instead, create a unique identifier specific to your app.)
@property (nonatomic, readonly, retain) NSString *uniqueIdentifier
Special Considerations

Do not use the uniqueIdentifier property. To create a unique identifier specific to your app, you can call the CFUUIDCreate function to create a UUID, and write it to the defaults database using the NSUserDefaults class.

When making this change, it is important to note the differences between the UDID and the new UUID. The UDID was a unique identifier for your phone that was the same across all applications. It remained constant even when you deleted and reinstalled an application, allowing for the application to still know who you are. Now, with the UUID created through CFUUIDCreate, it is only unique for an app, and on one particular install. Once you delete and reinstall the app, a new identifier is created. If you do need the new UUID to last beyond app deletion and reinstall, the value could be stored in iOS’s keychain instead.

If you would like to know more about the implications that this will have on your app, do not hesitate to contact us for more information.

Cross-posted from the Xtreme Labs blog.