iOS 5 deprecates UDID as identifier for developers, but it's not the end of the world

Reading the headlines today, you'll see the usual exaggeration of half-understood factoids bubble out from today's iOS 5 beta 6 release. Thank goodness for that NDA, huh?

As reported by our sister site TechCrunch, Apple is deprecating the use of UDIDs as unique identifiers for developers, thereby severing one of the most common ties between physical devices and the apps that need to know which specific iOS gadget they're on. It's the end of the world as we know it! Well, no, actually. Let's get to the real story here, brought to you by feedback from some iOS developers with real-world knowledge of what the implications of this change will be.

First off, let's clear up what it means for Apple to 'deprecate' this identifier. A deprecated function or software component is not yanked out immediately; it's simply been flagged by the developer of the platform (or app, command line tool, what have you) as something that will be going away in the future, eventually. While the feature remains in place for the sake of backwards compatibility, deprecation is a clear sign to all the programmers in town that they will have to move away from using this feature in the long run.

To the average person, this deprecation of developer access to UDIDs means little more than one step towards better privacy. UDIDs are far from the only way a developer could ensure "your" iPhone is, in fact, your iPhone. Using the identifier has always been a relatively easy way for developers to do this, however, and so many used it, some abused it, and the average user was never the wiser.

From the beginning, Apple has always uniquely identified its devices via UDIDs or other means, and the iPhone is no exception. There is a class called "UIDdevice" which describes the things on the iPhone, i.e., the features unique to that device. Until today, developers could have access to a users' UDIDs, and they've used them as identifiers for a lot of gaming, user info persistence and subscription systems (including some of our favorite apps). The downside of UDIDs in the past is because they're related to devices and not accounts, sometimes it's hard to have the device identifiers talk to each other. Some developers have grabbed or scraped these without user permission for marketing and other less than reputable purposes -- hence the privacy concern behind broadcasting UDIDs to third-party developers.

The utility of developers having access to the UDID is far lower than the potential for abusing it. The UIdevice class does things like telling you the battery state, system name, OS version, phone model, and so forth -- it identifies the device and the features on it. It's been helpful in terms of letting developers determine which devices run certain features better -- knowing the difference in performance between an iPhone 3G and an iPhone 4 is certainly important, especially to game developers -- but other than that, there's not much utility there.

So why isn't losing access to the UDID a big deal, at all? Any developer can always roll their own unique identifier. Apple provides a way to randomly generate one, so you never really had to use the UDID. People have been using UDIDs for various reasons -- not all of them good -- and there's not a lot of positives to UDID use other than ad-hoc app distribution (i.e., for beta testing).

Apple's deprecation of UDID access is something that's been expected for some time. MacStories' take on it aligns with our own; privacy concerns over UDID sharing have been in the news for a long time, so it's not a shocker that Apple's now contemplating denying third-party access to them. From a user's perspective, this is a Good Thing. From a scrupulous developer's position, this may complicate your life for a while, but that's all. Unscrupulous developers who've been abusing UDIDs for marketing or other purposes are the ones that will get hit hardest by this change, but as far as I'm concerned, they can wither up and die with no tears shed.

Some have speculated that iCloud account information might be substituted for UDIDs, but developers don't really have access to user account information from iCloud -- and they shouldn't. That would be an even bigger security hole than UDIDs.

Apple seems to be taking a "none of your business" approach to user IDs where developers are concerned. We speculate that's the motivation behind removing the UDID API. Meanwhile, try not to buy into widespread reports of dogs and cats living together/mass hysteria, because it's just not that big of a deal in the long run.
Share