/article-new/2011/06/ios5_icon.jpg?lossy){kind=icon}
TechCrunch reports that Apple is making an interesting change in iOS 5, phasing out the ability for developers to access a device's Unique Device Identifier (UDID). Apple is instead asking developers to create unique identifiers specific to their apps in order to tie installations to specific users.
This is a big deal, especially for any mobile ad networks, game networks or any app which relies on the UDID to identify users. Many apps and mobile ad networks, for instance, uses the UDID or a hashed version to keep track of who their users are and what actions they have taken. App publishers are now supposed to crete their own unique identifiers to keep track of users going forward, which means they may have to throw all of their historical user data out the window and start from scratch.
Apple and a number of app developers have been sued over their handling of UDIDs. While UDIDs can't directly be linked with a specific users, information tied to a device can be passed along to advertisers to help them in targeting their advertisements, with some privacy advocates objecting to the practice.
With the UDID, ad networks can track what apps are being used on a given device, enabling them to piece together a valuable picture of activity conducted on a specific device. Apple's move seems to specifically address that concern, breaking down identifiers to the app level to limit the ability to put together such a complete picture.
Top Rated Comments
UUIDs are typically used as database keys in apps that connect to servers. So why are they being deprecated?
Because UUID's uniquely identify a device, not a user. This is problematic in several scenarios:
* users with multiple devices. If a user has both, say, an iPhone and an iPad, and an app that runs on both of them, they want the same data to be available on both devices. Using UUID as an identifier means this doesn't work. If an app was storing some server-side data for me, this would get lost.
* devices with multiple users. iOS doesn't currently support multiple users, but maybe it will in the future. Using a user-based identifier will be needed to make this work.
* upgrades. When I upgrade my 3GS to a shiny new iPhone 5 in October, the UUID will change. If any app was storing data server-side based on only my UUID, that data would become inaccessible.
With iCloud, Apple now have a fairly reliable way to identify users rather than just devices. Since developers can make use of iCloud too, this is presumably the recommended way going forward. Hence the UUID deprecation.
This passes the blame to the developers and not Apple now. :D
Apple's just protecting themselves on this one.;)
1) To finally put an end to incentivized installs through networks like TapJoy and Flurry (they currently are able to track installs by users' UDIDs)
2) To begin the change to associate all of the app's content to the user's Apple ID through iCloud
It will be a bit of a pain as a developer, but it makes sense.
EDIT: As some people have noted, I do NOT think that the large number of people getting pre-access to iOS 5 has to do with this. They can solve that by a much simpler solution.
And where exactly is your proof that Apple uses the UDID for anything other than what it is meant for? Again, Apple doesn't need your UDID, even for its iAD ads. They already have information on you from other sources that you gave them. Google does the exact same thing... You create an account for a Google service and they have your information that they can use to target ads at you, they do not have to share this information with anyone else... How is that different from what Apple is doing? I can't remember ever seeing another ad network post ads all over Google's services.
Also, the UDID is tied to a hardware device, not a person, trying to link the two means a possibility of your data being merged with someone who later owns that device after you no longer own it.
Sorry, but tough **** for OpenFeint. As a gaming network their only course of keeping track of users should be through a voluntary account creation and login by the user who's interested. This applies to EVERYTHING. If I'm interested in the service, I'll sign up for it!
I've only been coding since 1981, starting with BASIC, then 6502 Assembly, then MC68000 Assembly, DOS Batch files, Pascal, C, C++, SmallTalk, Objective C, Javascript, PHP, UNIX Shell scripting, etc... First on an Apple II, then IBC PC, AT&T System V System, Classic Mac OS, Mac OS X, WWW, iOS.
Uh the last time I checked, I've never been able to do a straight copy of code from one language to another across platforms... code across languages is not syntactically the same and API's across platforms are not the same either. You cannot transfer code from one language/platform into another without making changes.