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 ar…
> 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…
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.