[gilgoomesh]

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]

> 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]

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]

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]

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.

[blueprint]

That's what I get for informing others of something I hadn't actually confirmed. Thanks for the correction. :)

[tstyle]

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]

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.

[ryanpetrich]

I suspect access to MAC addresses will go away at some point—it has the same privacy concerns as UDID.

[lkesteloot]

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

[erichocean]

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.

[gurkendoktor]

I have an iPad 1 that was adequate to surf the web on iOS 4.3, and I will never be able to downgrade to that version again. Now I have a brick on iOS 5 (unbearable out-of-memory crashes). I earn my money on iOS and I still can't really cheer at handcuffs. =/

[fnayr]

And more than 30% for me.

[gurkendoktor]

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]

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

[gurkendoktor]

Some apps push data into the cloud without asking/having an option. For me this was Screens VNC, which synced semi-confidential information across my two computers without asking (all my bookmarks, except for the SSH/VNC passwords).

Arguably the external IP, SSH port, SSH username, internal IP and internal username of my client's confidential computer are only "security by obscurity", but I'd still rather have everything on my hard drive only by default.