Apple let it be known back in August of 2011 that they'd be deprecating developer access to UDID ( Universal Device Identifier), they've now taken the next step and begun actively rejecting App Store apps that use it. The fine developers of Tweetbot have reported that one of their latest updates was rejected from Apple for collecting UDID information without getting user consent first. What does this mean for apps like Tweetbot?
[UDIDs] allowed us to restore push notifications settings after Tweetbot was deleted and re-installed. With this new change in place this is no longer possible, if you delete and re-install Tweetbot you’ll have to setup your push notification settings again.
The UDID is 40 characters that are unique to your iPhone and iPad, used most generally by developers to provision pre-release apps through the App Store. Now developers will need to create their own unique ID within the app and store it in iCloud.
Ultimately, it's good news that Apple is making sure that developers aren't easily getting a hold on potentially sensitive data like UDIDs; iOS users are a little on edge about privacy after that Path incident.
This might also explain the speed with which Apple went from deprecating the UDID collection to outright rejecting apps. Typically something deprecated in one iOS version will be removed in a later version, giving developers time and an expectation for when they need to have an alternative approach in place. This has led some developers, including
Source: Tapbots, Subfurther
Reader comments
Apple is now rejecting apps that collect UDID without permission
Wait! Does this mean that if I download Tweetbot I won't have Push Notification?
No, it just means if you download it, delete it, and reinstall it, you will have to do some setup steps again, rather than have the app know enough to do it for you.
GOOD. About time...
Agreed. There is no reason for a mere Twitter client to access any device's UDID.
First off, I have no problem with Apple getting stricter about UDID collection. However, the way they are going about it is arbitrary and unfair to developers. Last August's announcement made it halfway there, but was not enough. The answer, as always, is honesty and transparency to developers.
The proper way to deprecate (or change the usage of) APIs is to indicate they are going to be removed, and then provide a release version and target date where they will be no longer usable. Anything less, and you force developers to guess when it will take effect, and it is very difficult to prioritize your own effort/money in the face of that much uncertainty. I have no doubt Apple is doing this faster than they wanted to after Path and pressure from Congresscritters, but that just makes the problem worse. Now, Apple is forcing developers not only to read Cupertino's mind, but to guess how third parties (governments) are going to react to Cupertino's decisions, and how in turn Apple will react to them. An honest, specific roadmap of the type every platform/library provider has -- even Apple with OSX -- would have solved the problem completely. Something like:
1) August, announce that UDID collection will be deprecated.
2) Either in August, or in the next SDK release, specify it will be removed as of future version X, with a target release date of Y
3) Developers like Path, and like Tweetbot now know exactly when they to have this finished, and they can prioritize it against other features and bugfixes. Developers appreciate this. Developers need this.
4) When Congress comes a-calling, Apple can soberly tell Senators that they understand the importance of privacy, and have already taken proactive steps to address the issue by Y. To Congressional pressure for alacrity, Apple can respond that they are moving as quickly as possible without costing job loss among a portion of the tens of thousands of developers whose livelihood depends on the App Store. Apple looks balanced, and legislators on all sides then have their talking points. Congresscritters appreciate this.
This sort of transparency is a win-win; the only thing it costs Apple is the ability to knee-jerk respond to outside pressure, something which a platform provider should not aspire to have.
This doesn't solve the problem with collecting UDIDs. Are they stupid? All this does in require the app company to put in an accept button for you to accept it. If you need to actually keep and use the app, collecting your UDID without you knowing or with you giving concent is EXACTLY THE SAME THING!!! What Apple needs to do is do away with their ability to collect the UDID or put in a security measure to deny access to the UDID but still be able to use the app. The process should be the same as giving permission to use GPS for an app. (i.e. you deny the permission, but the app still functions without it.)
I noticed in the cocos2d engine they have the deprecated tag....
Are all apps using cocos2d going to get rejected? I can't believe that is the case.
First class weblog, thanks for sharing this post