

Essentials of Apple’s UDID - graiz
http://blog.appblade.com/news/2011/08/essentials-of-apples-udid/

======
epoxyhockey
What about push notifications? I think that's the biggest legitimate use of
UDIDs and was not mentioned in the article.

According to the docs, every time an iOS app starts up it sends a device token
to the push provider. From time to time, this device token changes, so it is
nice to have the token linked to the UDID so that one doesn't try to send push
notifications to invalid device tokens.

Reference:
[http://developer.apple.com/library/ios/#documentation/Networ...](http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html)

~~~
msftguy
It's handled when your push service trims out dead tokens, which it needs to
do periodically anyway.

~~~
epoxyhockey
Thanks for that info, I somehow overlooked this when rolling my own push
provider.

For those still interested: There is a separate feedback service
(feedback.push.apple.com) that providers should query periodically. It returns
a list of device tokens that are no longer valid for your application.

Reference:
[http://developer.apple.com/library/ios/#documentation/Networ...](http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW4)

------
Greenisus
As an app developer, I have to say I agree with Apple on this decision. The
UDID is harmless to share, but in the days before TestFlight when I would send
out Ad Hoc builds to test apps before publishing, many people would get
nervous about sharing their UDID with me. I'd often be asked "is this safe?
Can you hack into my phone with this?"

Of course, classic Ad Hoc builds will probably still require handing over a
UDID, but I would think it would be comforting for the average iOS user to see
stories like this, because it gives the illusion of a little extra security
and certainly helps regarding privacy.

The only thing I'm worried about is how this will affect TestFlight. Without
programmatic access to the UDID, the on-boarding process for a tester in
TestFlight is going to become much more complicated.

~~~
j_kauf
This change doesn't prevent reading the UDID through the web browser using a
configuration profile. The article points out that AppBlade and similar
services will continue to work just fine.

~~~
Greenisus
Ah cool, didn't notice that

------
gyardley
Some misconceptions here.

 _There are analytics and demographic research companies that actively buy and
sell this data for very large sums of money._

This sounds believable - people are buying and selling my valuable data! - but
it's completely mythical. (I wish it were true, since I'd be a lot richer.)
Behavioral targeting data from application usage isn't worth a hell of a lot,
especially since it can't easily be linked to profiles on the mobile or
broader web. Analytics companies don't buy data at all and have difficulty
selling it, if they're even attempting to - there's not enough money in it to
make it worthwhile. Demographic research firms have all constructed their own
small panels with full user opt-in, and the other interested parties out there
aren't paying very much.

You can make a little bit of money off of usage data, but not enough to
support a company.

 _The UDID is currently the only way to track an advertising conversion from
an ad in one app to the installation of another app._

Well, it's currently the easiest, most reliable, and most user-friendly way -
so it's the one everyone uses. The article itself goes on to mention some of
the alternatives, so this is a curious assertion.

 _[T]he prevailing attitude around Apple violations is “we’ll know it when we
see it.” Workarounds that break the spirit of a rule are likely to be rejected
just the same._

It's just as likely that the services will continue using the deprecated but
still available UDID call. If Apple decides to test for and police UDID usage
or any other workarounds, they absolutely can, but that decision's up to
Apple. If the subset of application developers important to Apple wants cross-
application tracking, I suspect there will be a way to do cross-application
tracking.

We'll only know the real implications of Apple's UDID deprecation after iOS 5
is broadly deployed.

~~~
graiz
> actively buy and sell data for very large sums of money.

This is happening and we've been approached by firms with non trivial offers.
This is typically associated with shopping/e-commerce apps that can use the
data to impact conversions. Companies targeted with these offers tend to
collect billing/shipping information to further tie data to existing retail
habits. (FYI: We said no thanks.)

> attitude around Apple violations.

The attitude is there but you are right that they haven't rejected apps for
UDID usage, yet.

------
conradev
Just thought I'd share how a UDID itself is generated:

<http://iphonedevwiki.net/index.php/Lockdownd>

~~~
graiz
Interesting:

UDID = SHA1(SerialNumber + IMEI + WiFiAddress + BluetoothAddress)

