iOS developers: Say goodbye to UDIDs

iOS developers: Say goodbye to UDIDs(developer.apple.com)

89 points by chillericed 13 years ago | 42 comments

gilgoomesh 13 years ago |

It's not a big deal. Just use the:

    [[ASIdentifierManager sharedManager] advertisingIdentifier];

for advertising across apps from different vendors or:

    [[UIDevice currentDevice] identifierForVendor];

for tracking your own library of apps or save a:

    CFUUIDCreate();

for tracking a specific app.

Developers who are upset that these IDs could be changed by the user if they restore their device or deliberately reset them are precisely the privacy violators that Apple are trying to eliminate. Yes, there are keychain tricks to create a more persistent ID (or MAC IDs to identify the device, regardless of user) but if you truly need long-term persistent, unique identification users, have them log into your service instead of trying to steal their identity without permission.

Edit: I forgot to mention another clean option for persistent identification... store a uuid from CFUUIDCreate() in an iCloud ubiquity container. Yes, the user will need to have an iCloud account and allow your app to store there. However, it does not require the user log into anything new and is the only measure that will follow a user through both app deletion and device changes (other than logging into your servers).

derefr 13 years ago | |

> but if you truly need long-term persistent, unique identification users, have them log into your service instead of trying to steal their identity without permission.

I think the idea here is that some services just plain don't have login flows, and are marginal enough that they might see massive use-decreases if they begin to hassle their users to create yet another account to use their service. If the user loses their vendor token for one of these apps, they'll have no way to get their data back; it'll be like their account just evaporated (which doesn't at all follow the Principle of Least Surprise, which to me might justify the use of these "more permanent" tokens to give users what they were expecting--persistent accounts tied to their device.)

This seems more like an argument for something like a "device profile" within your iCloud account--a generalization of device backups. Restoring the device and then logging back in with your iCloud ID would reattach the device to its profile, and then all your vendor tokens would be restored along with it, whether or not you chose to restore the whole device from a backup. Obviously, there would be an online interface to (selectively or completely) erase a device profile, achieving the same thing as a "token reset" but without the risk and allowing for a much clearer "you are doing something very permanent to your identity" signal.

cmelbye 13 years ago | | |

That makes no sense.

UDIDs are fundamentally flawed methods of associating data on your server with your users. The data loss scenario is similar to a scenario inherent in using UDIDs. Buying a new device means that you've lost all your data, with no way to restore it to the new device (besides creating a fully-fledged sign up system, which you've ruled out.)

Vendor identifiers fix this. The vendor identifier is only lost when the app is uninstalled. It's backed up and can be restored onto new devices when you upgrade.

Do you really think it's surprising to lose your data when you uninstall an app? It completely follows the "Principle of Least Surprise" to lose your data, it explicitly says you'll lose it when you uninstall apps. If you want to persist data beyond the lifecycle of an app installation, you should probably consider a sign up system at that point.

blueprint 13 years ago | |

Heads up to iOS devs: the advertising identifier is generated and changes each time that method is called. Generally a good idea to store it in user defaults or keychain and check for it before generating a new one. More info there http://stackoverflow.com/a/12933454/122115

xsmasher 13 years ago | | |

The advertising identifier does not change on every call.

Using "CFUUIDCreate" IS WRONG, though. It generates a GUID. That's what CFUUIDCreate is supposed to do. But it's the wrong method to call to get the advertising identifier.

You get the advertising identifier from ASIdentifierManager, and it does not change unless the user resets it.

tstyle 13 years ago | |

I've been using this library for my projects:

https://github.com/gekitz/UIDevice-with-UniqueIdentifier-for...

MAC Address based solutions are still okay right?

jayfuerstenberg 13 years ago | | |

Access to MAC addresses will likely never go away.

Also, if you don't need to identify devices per se, you can fallback on a generated GUID which you persist via NSUserDefaults.

It'll identify the user for the lifespan of that app install on the device.

lkesteloot 13 years ago | |

One problem with both advertisingIdentifier and identifierForVendor is that they are iOS 6+ only. That shuts out 10% of my user base.

erichocean 13 years ago | | |

I know you're complaining, but only having 10% of your users not on the latest OS update is really something we should be cheering.

The progress (some) OS vendors have made at keeping people current is really pretty fantastic when you compare to the situation 10 years ago.

fnayr 13 years ago | | |

And more than 30% for me.

gurkendoktor 13 years ago | |

The first two solutions are iOS6+ only, and the UDID never worked on iOS6. People who can live with cutting off iOS5 don't have a problem by definition.

Ubiquity container: Does anyone use and track this? How many % of people have iCloud enabled for third-party apps? (Just asking because I turn this off on all devices; I don't have any app that uses this, so all I am disabling is abuse)

pooriaazimi 13 years ago | | |

What kind of abuse? I'm (genuinely) curious, and being the paranoid OCD that I am, I'd very much like to know these things :)

fnayr 13 years ago |

The real story here is not the UDID ban which we knew was coming (and is easily counter-able as demonstrated in the comments already), but the forced iPhone 5 support.

Now this wouldn't be an issue except that Apple doesn't allow you to support the iPhone 5 without targeting iOS 4.3 or higher. So this kills off support for iOS 3.1.3-4.2. This might not seem like such a bad thing, but if you're targeting certain demographics like kids (as I am), it cuts off a significant percentage (7% in my case) of users.

buddydvd 13 years ago | |

Apparently, with the lipo tool, you can still support iOS below version 4.3 and Apple won't reject it.

See: http://stackoverflow.com/a/12678077

fpgeek 13 years ago | | |

Wow. The contrast with Android is stunning.

Google has been focused on enabling backwards compatibility since at least Android 1.5 (well before anyone knew how Android updates would play out in practice): http://android-developers.blogspot.sg/2009/04/backward-compa...

Meanwhile, Apple seems to prefer to make achieving backwards compatibility as hard as possible (short of explicitly banning it).

fnayr 13 years ago | | |

Whoa! Thanks for this! I would edit my original comment if it let me.

Still it is a hack that Apple could start disallowing at any time.

fnayr 13 years ago | |

Here's the announcement from Apple: https://developer.apple.com/news/?id=3212013b

nicholassmith 13 years ago | | |

Not sure how that's been passed up in favour of talk about the UDID change. That's quite a big move from Apple really.

KwanEsq 13 years ago |

Permalink: https://developer.apple.com/news/?id=3212013a

tqc 13 years ago |

Was there ever a good reason for using UDID anyway? The only examples I've seen are user tracking for ads (has privacy issues) or a horribly broken login system.

Anyone bothered by this is probably doing something wrong.

buddydvd 13 years ago | |

One use of UDID is verifying in-app purchase receipts. It's demonstrated in the sample code associated with Apple's article titled "In-App Purchase Receipt Validation on iOS".

See: https://developer.apple.com/library/ios/#releasenotes/StoreK...

tqc 13 years ago | | |

Never noticed that as I don't have any in app purchases that actually cost me anything. This usage would seem to be more because the ID is available rather than because it is needed though.

The bit about non-public APIs on that page is interesting though - if there is a genuinely necessary use case for device IDs it may not be affected.

seivan 13 years ago |

MacAddress or vendor identifier. You could also generate random... but it's a good idea to keychain it under its own namespace.

cynix 13 years ago |

I vaguely remember some apps using the MAC address of the WiFi interface as an identifier. Has this been banned yet?

forrestthewoods 13 years ago | |

Maybe yes maybe no, but either way that's not a good solution.

iOS 6 - use vendor identifier iOS 5 - create an ID via CFUUIDCreate() and save it iOS 4 - can be safely excluded from support

cynix 13 years ago | | |

> Maybe yes maybe no, but either way that's not a good solution.

I'm asking this as an end user - I want to see this usage banned so that apps cannot track me using the MAC address.

revetkn 13 years ago | | |

Vendor identifier is user-resettable. Storing UUIDs fails on reinstalls. MAC is persistent, as are other tricks like keychain storage

EGreg 13 years ago |

How will this affect TestFlight and other such apps? Don't they still need your UDID?

perkof 13 years ago | |

I beleive testflight doesn't use the App Store to deliver the application so should be okay.

An update to the testflight sdk should be sufficient for production applications with testflight integration.

Aqua_Geek 13 years ago | |

TestFlight gets your UUID by having you enroll your device in their MDM system. Support for this will likely never go away.

JimDabell 13 years ago | | |

They use the UDID when the application runs to associate particular sessions with particular users, which can be extremely valuable for debugging purposes.