Live data from Hacker News

iOS developers: Say goodbye to UDIDs

developer.apple.com

31–40 of 45 posts

Re: iOS developers: Say goodbye to UDIDs

#31

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…

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)

Re: iOS developers: Say goodbye to UDIDs

#32

Earlier quoted context omitted.

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

Re: iOS developers: Say goodbye to UDIDs

#33
post #29

Earlier quoted context omitted.

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.

Re: iOS developers: Say goodbye to UDIDs

#34
post #19

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 demog…

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

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.

Re: iOS developers: Say goodbye to UDIDs

#35
post #21

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

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.

Re: iOS developers: Say goodbye to UDIDs

#36
post #20
post #19

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 demog…

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.

Re: iOS developers: Say goodbye to UDIDs

#37
post #19

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 demog…

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

Re: iOS developers: Say goodbye to UDIDs

#38
post #37

Earlier quoted context omitted.

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.

Re: iOS developers: Say goodbye to UDIDs

#39
post #34

Earlier quoted context omitted.

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

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.

Re: iOS developers: Say goodbye to UDIDs

#40

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…

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 :)
Post reply on HN