If Apple is really rejecting apps over use of UDID, the lack of alternatives is a problem

Apple has been warning developers since August of last year that they should stop referencing the UDID (Unique Device identifier) of iOS devices in their apps. The ID itself is harmless, and carries no personal information about a user, but it can be combined with information gathered in an app to track people across, say, an ad network.

We’ve been investigating tidbits of information for the past week or two about apps possibly being outright rejected by Apple for using the UDID, despite being warned off of it. At this point, we have not had a single direct confirmation of an app that uses a UDID to keep track of devices being rejected by Apple, despite some comments on Twitter.

However, in an article by Kim-Mai Cutler at Techcrunch, she says that she has gotten confirmation from Andy Yang of app monetization company Playhaven that some of its clients have had apps rejected for doing exactly that. It seems that she has done her due diligence, so there is enough smoke to assume that there is a fire here.

But the problem with all of the takes on this so far, which are generally just parroting of Cutler’s report, is that Apple flat out told developers to stop using UDID back in August. When a method is ‘deprecated’, it means ‘stop using it, this thing is going away’. This sentiment was echoed by Apple Developer Evangelist Michael Jurewitz last week on Twitter as well, after being quizzed about whether continuing to use the method would result in rejection.

@drbarnard you should be moving away from it regardless. It’s deprecated.

— Michael Jurewitz (@Jury) March 22, 2012

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

There were also reports in February that Apple had been reaching out proactively to recommend that developers drop UDID usage from their apps.

The thing about UDID is that its not inherently a bad idea to have a way for developers to tell that you’re using a specific device with their apps. Developer David Barnard, who asked the question above, uses the UDID of a device to aid in synchronizing data from one copy of App Cubby’s apps on a device over to one running on a different device. If the servers couldn’t tell one device from another, there would be a mess and they wouldn’t be able to offer those syncing services.

Another example is effective push notifications. Popular Twitter app Tweetbot uses the UDID to tell which devices to send the messages to, and which have received them already. The problems surrounding the loss of UDID aren’t all centered around ad networks and tracking users in order to sell them things.

There are plenty of very legitimate situations in which a developer might need to make sure that an app is sitting on a unique device that don’t involve ads. Apple knows that it needed to offer developers an alternative if it wanted them to stop using it, so it recommended CFUUID (Core Foundation Universally Unique Identifier).

But not everything is wine and roses with CFUUID, there are some issues around it that make it a poor alternative for some apps. A CFUUID is generated when an app requests it from iOS, and it’s up to the developer to store it somewhere. But that value can be deleted and there is no way to get it back. In contrast, a UDID is generated once and stays the same for the life of a device.

The CFUUID is problematic,” says Paul Haddad, of Tweetbot studio Tapbots. “If you restore a new device from the backup of an old device you’ll get two devices with the same CFUUID. If you restore the OS from scratch you’ll end up with the same device with two different CFUUIDs.”

There are other alternatives as well, but they offer their own unique problems. Using the MAC address, the ID of a device’s network hardware, is one that is commonly offered, but that is just as permanent as a UDID and is often used by network administrators to restrict access. A MAC address can often tell hackers many things about where your device has been as well, and if Apple is banning UDIDs, it’s likely that they’ll be after MAC addresses next.

“If you need a bullet proof way to track a specific device, there is no good alternative to the current UDID,” says Haddad. This lack could end up causing a lot of heartache for developers as people wipe, restore, upgrade and switch out devices. Ad networks and others who use user tracking to make money are obviously worried, but developers that are just looking to provide a better user experience will also be affected.

There are some theories about possible alternatives, like performing a cryptographic hash using the current UDID or MAC address and the app’s ID and using that as an identification number that would be unique per app, per device, but wouldn’t be useful to track users across multiple apps. There are also a couple of companies like Openfeint and Appsfire that offer alternatives that work within the ecosystem of apps that use their sign-on systems. (Note: Appsfire’s Yan Lachelle notes that its OpenUDID is an open-source replacement that is not linked to a sign in.) But there are not likely to be any universal methods that stick unless Apple backs them.

There is a very simple reason that Apple is so down on UDID. It’s an easy way for advertisers and developers to track a specific device, and therefore its owner, across a variety of apps and ad networks. This is the kind of thing that gets privacy commissions and watchdog organizations up in arms. Apple saw the writing on the wall last year, before the Path debacle caused scrutiny toward how iOS apps were using personal data and Congress took a direct hand in quizzing iOS developers about how they complied with privacy policies.

We will continue to monitor the situation to see if we can confirm that apps are indeed being rejected, but regardless, its a good idea for developers to start implementing alternatives, no matter how problematic.