/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.
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.
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.
No but UDID is good for selling ads as it collect better metrics off a single user that can be linked together. For individuals apps not so much but for say any that sell ads a lot more info or it can be used to help track if a user is using different apps from same dev. Yeah having an App generated an ID key is easy but having that key shared between apps not so much, big time in Apple's wall garden approach. UDID got around that issue as they did not need to share and access data from each App.
So you're saying you're all for being profiled by ad networks without your consent!? Really!? This is exactly why Apple wants this abuse stopped. It's nonconsensual use of my information and an invasion of my privacy.As I pointed out UDID is great for things like Google Ad words for tracking user data. Apple blocking it means Apple gets all that data Google gets none. I know Google ads and Apple ads are not the only 2 companies that sell ads but guess who gets better user metrics to sell ads with due to this blocking. You guess it Apple. You have failed to address that argument.
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.
As for Openfeint. I think you can created an account but it defaults creating one based on the UDID.
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!You have not coded much have you. A lot of the code can be transferred between devices and not a large amount of things have to be changed. Losing the UDID means you have to now changed even more things in the code and their might not be an equivalent other platforms. That is where you have to do the extra coding. Modern IDE make the basic stuff really easy to do. It the fine tuning and testing that takes a little longer but most of the stuff is able to be transferred straight over.
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.