With the introduction of iOS 5, Apple implicitly indicated that it will soon remove the ability for developers to access the unique device identifier, also known as UDID. While not the most important API in the entire iOS SDK, many in the app ecosystem have grown dependent on this UDID, for legitimate aggregate measurement needs, not for individual tracking purposes. The problem is real and yet both sides of the solution (!) have legitimate claims. A recent article on TechCrunch articulates the mobile conundrum very well.

In anticipation of this imminent restriction (which in some cases already appears to be enforced as alluded to here or here), a number of actors have adopted a substitute open-source approach that Appsfire helped bootstrap: OpenUDID.

In no particular order: Inneractive, Trustee, adFonic, Greystripe, Crashlytics, Lumi Mobile and us, Appsfire, among others, are supporting, have implemented or are planning to implement OpenUDID in their apps and their processes, with many more in the process of joining.

Why does a UDID matter?

App publishers need a reliable, consistent and transparent way to measure conversion rates between the source of a click to actual downloads. Typically, banner ads or even Apple’s own iAd for that matter, keep a tally of how many clicks lead to how many downloads. Since downloads could come from anywhere, then it’s important to match with the source. On the web, cookies are used to accomplish this sort of tracking. Native mobile apps use a unique device identifier - which Apple will be removing anytime. No device identifier, no tracking, and no way for publishers to check whether their advertising campaign is efficient and whether they are getting their money’s worth.

Enter OpenUDID

OpenUDID meets the industry need highlighted above, and will safeguard prior investments if and when Apple flips the switch. It’s a drop-in replacement for the native UDID: open-source, transparent, cross-app, and persistent across reboots and restores. Something that the original UDID lacks is an opt-out system; OpenUDID has opt-out built-in. As a bonus, the community has already expanded on the initial OpenUDID implementation, now supporting Android and Mac OS X.

Blackberry, and Windows Phone 7+ implementation is sure to follow.

New opportunities

Third parties can even probe the OpenUDID structure and create apps or services around the tracking topic:

• Apps to help users opt-out selectively on their own device
• A service that produces reports on apps that use OpenUDID
• A central authority that validates best practices and provides seals of compliance

How does it work?

Technically, OpenUDID uses a mix of local app storage for cache and safeguarding, as well as inter-app storage (custom pasteboards on iOS). This means that the system is decentralized, neither controlled by Apple nor anyone else. The more OpenUDID is used, the more robust and prevalent and tamper proof it gets.

Other than that, the OpenUDID looks and feels the same as the native UDID, a 40 characters long hexadecimal string. For instance:

369416e16c373b617b2e4d151e01244c748c7b3e

OpenUDID vs. the MAC network address

Other initiatives involving the MAC (network) address have sprung up. Indeed, the MAC address can be considered as a fairly unique device identifier. And yet, it is a very sensitive piece of private information, sometimes used to authorize devices on private networks. We are totally opposed to using the MAC address (and we think that Apple and other platforms will too). Using this key for tracking will certainly lead to yet more malpractice, hacking and therefore security breaches, and then more deprecation from Apple.

Our message here: DON’T USE THE MAC ADDRESS! IT WILL FIRE BACK ON YOU!

The way forward

Move to OpenUDID today. It’s a plugin replacement. All you need is download some simple code from github http://openUDID.org
Feel free to contribute code, unique key generation, porting, etc… it’s easy to branch-out and grow the effort on GitHub.

Next: We are in the process of contacting Apple to let them know what the industry needs, and how to fix it permanently. In fact, you already know where this is headed: an opt-in panel inside the systems preferences, just like the one that already exists for Location/Notification and soon Address Book and Calendar events…