[note: this is technical post for iOS developers, publishers and ad networks]

Do you remember all the fuss about UDID? Yup, the dust has settled on this one, like most things. But today is the right day to revive the topic!

UDID tracking posed a number of ethical and user privacy concerns a few years back, yet it was the most efficient way for advertisers to track the efficiency of their campaigns.
This short blog post will briefly cover the past, the present and the future of such identifiers, especially as applied to advertising tracking.

In a few days, many of us are expecting the formal announcement of iOS 7 at the WWDC keynote. Whether or not iOS 7 is announced, the reality is that iOS 6 adoption has by now eclipsed previous iOS instances and iOS 7 will put a nail in the coffin in terms of iOS5 and lower versions, which should plunge well below the 10% watermark.

By way of inference, and given the fact that the uniqueIdentifier API (aka UDID) is now private/forbidden, we can safely say that the advertisingIdentifier API is almost universally appropriate to track ad unit conversion rates…
[and for anything else, there is the vendorIdentifier API – the MAC address is not an option, it’s a big NO NO!]

So, what does this mean for OpenUDID, the open source drop-in replacement brought to you by Appsfire that helped bridge the gap since the summer 2011 deprecation of UDID with the announcement of iOS 5?
Well, it’s quite simple: It’s now time to deprecate OpenUDID as well!

No rush, no guillotine, no deadline – in fact deprecation doesn’t strictly apply to open-source projects!
In fact, OpenUDID might at the fringe remain useful for a little while longer as part of iOS 4 and iOS 5 support, each with a rapidly shrinking user base.

In clearer terms though, the essence of this post is to suggest that all efforts to integrate/improve OpenUDID should cease now.
advertisingIdentifier works well and was the right move by Apple. It is also now time to start implementing the advertisingTrackingEnabled logic; don’t wait until Apple formally requires it!

  • Lars Klassen

    OpenUDID is still useful even on iOS6. I myself us it due to a bug in iOS6 that returns invalid UDID on vendorIdentifier (either the return value is null or 0000-0000-0000).

    But it’s true, this probably will be fixed at some point.

  • sjs

    iOS 7 Beta 3 released today breaks +[UIPasteboard pasteboardWithName:create:] as used by OpenUDID. Now named pasteboards will be unique to a given vendor rendering them useless for cross-app tracking. Long live the idfa!

    • Yann LECHELLE

      We’re not supposed to talk specifics here… but correct, OpenUDID has in fact no future under iOS 7

  • Lex

    typo: Apple “formally” requires it

    • Yann LECHELLE

      Nice catch! Typo fixed!

  • jo

    Why not use the ASIdentifierManager for IOS7+ and the logic you have now for the other mobile platforms so a developer just needs to learn one API ?

    • Fed

      I think this would be the optimal solution…

      • Yann LECHELLE

        Unfortunately, the entire stack itself needs to be repurposed and re-engineered as the notion of UDID itself (baked into the title of OpenUDID) is fading away. There are multiple identifiers that can and should be used depending on the situation. OpenUDID merely tried to address the deprecation of UDID which was later replaced by not just one but two key and relevant identifiers: VendorID and identifierForAdversiting, itself bound to the opt-out and reset procedures allowed by the OS. Both serve a purpose and a distinct one. It is best that developers now take act to use these new identifiers.

  • isneyl16
  • Fabio Caccamo