
iOS developers: Say goodbye to UDIDs - chillericed
https://developer.apple.com/news/?id=3212013a
======
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).

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

~~~
buddydvd
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>

~~~
fpgeek
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...](http://android-developers.blogspot.sg/2009/04/backward-
compatibility-for-android.html)

Meanwhile, Apple seems to prefer to make achieving backwards compatibility as
hard as possible (short of explicitly banning it).

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

------
KwanEsq
Permalink: <https://developer.apple.com/news/?id=3212013a>

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

~~~
buddydvd
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...](https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/index.html)

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

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

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

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

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

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

~~~
forrestthewoods
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

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

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

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

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

