[shangrila]

Most of the UDID replacement "solutions" proposed so far are just cookies. They generate an identifier and write the data to a location such as the keychain, or a private pasteboard as in the case of SecureUDID. These locations may be somewhat persistent and might even outlast a delete & reinstall of a particular app in some cases, but in the end they are still volatile and therefore do not actually identify devices. The information can still be lost in the event of an OS restore.

For some (most?) developers, this might be sufficient. But if you need to actually, truly identify devices, these solutions are not good enough. The only way to identify a device itself is to use actual hardware-specific info. Since Apple is removing the UDID, the WiFi MAC address is pretty much the only thing left.

Any solution not based on hardware-specific info but which pretends to "distinguish devices" (as SecureUDID does) is not actually doing what it claims to do. It's a subtle but important distinction.

[mattmass]

Your point is completely valid. These aren't guaranteed to persist across all events, though OS installs should be ok if the user restores from a backup afterwards. The ability to delete/turn off is important, though. A tracking number that cannot be deleted and is shared across all applications is fundamentally at odds with user privacy.

SecureUDID does not claim to emulate a hardware ID. Uniqueness-per-app-only and ability to be disabled are its two defining features.

[tejaswiy]

Agree. But I've been wondering what exactly do people want with a "Device ID"? I've changed my code to generate a new GUID and save it to NSUserDefaults. Sure, it doesn't persist even across app reinstalls, but so what? I maintain it as a currently active device ID instead of a unique device identifier..

[hboon]

It's often networks providing advertising or analytics services that want to identify devices. Not the app/service itself.