iOS developers: Say goodbye to UDIDs | Hacker News Reader

iOS developers: Say goodbye to UDIDs

developer.apple.com

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

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

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.

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

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.

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

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?

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.

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

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

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.

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. =/

And more than 30% for me.

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)

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

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.

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.

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

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

OTOH when developing for Apple platforms there's not a huge loss when developing only for iOS 6+ (85% - 90% of users), whereas on Android you're pretty much required to target very outdated versions of Android as well. For example we target Android versions starting with Froyo.

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.

I don't think the lipo tool will ever be regarded as hack. It's pretty much required when supporting multiple architectures / instruction sets. At some point there will likely be a ARMv8 architecture (if it doesn't exist yet).

Also many libraries make use of lipo to create convenient static binaries that can be used both in the simulator as well as on the device.

Well what I mean is I believe Apple will start rejecting apps at the review stage if they see its built with armv6. (Of course it's just my guess).

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

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.

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

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.

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

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.

The UDID embedded in receipts prevents/deters people from sharing them with others using MITM techniques. Sharing does happen and Apple's article helps address that issue.

True, but that is only one solution and a flawed one, as device ID can legitimately change - no developer needs to know whether I am using the phone I bought today or the one I bought a year ago.

Non-consumable in-app purchases are restorable on any iOS device you can sign in with your iTunes account. When you buy a new iOS device and use StoreKit's restore transaction feature, Apple will generate a new receipt with UDID of that device. In-app purchases are tied to your iTunes account whereas embedded UDIDs are tied to devices you sign in with your iTunes credential.

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

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

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

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

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

> Vendor identifier is user-resettable.

And that is a feature, not a problem to be worked around. :)

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

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.

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

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

Reply on news.ycombinator.com