iOS developers: Say goodbye to UDIDs (opens in new tab)

(developer.apple.com)

89 pointschillericed13y ago42 comments

42 comments

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).

derefr13y 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.

cmelbye13y 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.

blueprint13y 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

xsmasher13y 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.