iOS Developers Must Say Goodbye to UDIDs

iOS Developers Must Say Goodbye to UDIDs:

Apple Inc. (Photo credit: marcopako )

This guest post was written by Appsolute Genius CTO Andria Jensen.
Apple recently started to reject apps which use a Unique Device Identifier (UDID) to identify the device itself.  The UDID has been used since the beginning of app creation to link a unique device (iPhone, iPod, or iPad) to an app or user account, and in turn recognize that device later to maintain settings, data, etc. contained in the app for a specific user.  For anyone not familiar with the UDID, think of it as a social security number for apps.  On its own, that number may not be very useful to someone who gets their hands on it.  But, when combined with other identifying information, such as name, address, date of birth, etc. it can lead to a lot of privacy issues.
A popular twitter app, Tweetbot, was recently rejected for using the UDID in their latest update, with Apple citing privacy issues as the reason for the rejection.  Their blogpost about the rejection has gotten many iOS developers in a panic about what to do in their own apps so they aren’t facing a rejection with their next submission.
In Apple’s defense, developers have known about this new guideline since August 2011, and have been warned that eventually the support for UDIDs would be removed altogether.  But, as developers generally do, many of us have waited until the last minute to switch over our code from UDID usage to something else.  So, if you are one of those developers, here are a few situations where you may be using UDIDs and what you can do to comply with Apple’s new guidelines:

• Problem:  You use Flurry, Urban Airship, Localytics, or some other 3rd party SDK which makes use of a UDID.
• Solution:  Many apps use services such as Flurry for analytics or Urban Airship for push notifications, both of which have historically used the UDID to identify iOS devices.     Flurry and Urban Airship have both released new versions with a different approach to device identification, which will replace the UDID and allow apps to comply with Apple’s guidelines.  Ad SDKs are generally pretty guilty of collecting identifying information, and the UDID is no exception.  If you are using something other than iAds at this point, be sure to verify that the SDK you are using is not collecting UDIDs.

Almost any well-supported or paid service has already upgraded their SDK to make use of some other identification means to replace the UDID.  All you should really need to do is upgrade to the latest version of the SDK.  However, if for some reason the particular SDK you’re using has not yet addressed the UDID problem and has not announced plans to, you may want to start looking for its replacement.

• Problem:  You use the UDID to authenticate the device as unique for a particular user of the app.  Maybe your app restricts the user to only a certain number of devices, or in the case of some banking apps, uses your UDID to help identify you as a trusted user of your account.  Many apps, games in particular, have historically used the UDID to create a user account and profile, to bypass a more cumbersome registration process.
• Solution:  Apple has provided a recommended way to generate a uniqueIdentifier.  They have suggested calling the CFUUIDCreate to create a UUID, and then writing it to the NSUserDefaults for the app.  This will create an ID unique to the app/user combination.  If that user uses a different app (even in the same suite of apps), a new UUID would be assigned for that app/device combination.

• Problem:  You store app settings specific to the user’s device on your server, so that the device settings can be restored if the app is deleted and reinstalled at any time.
• Solution:  Implement iCloud in your app.  You can store any settings or data that needs to persist in iCloud, by using the key-value or document storage.

• Problem:  You MUST have a unique identifier for the device – not the device/app combination.  It has to work exactly the way the UDID did.
• Solution:  I must admit, I can’t think of a case where this is a true must, but I’m sure that someone could convince me otherwise.  If you must have a true UDID, a few 3rd party solutions have presented themselves as ways to replace the UDID.  Companies such as OpenFeint, AppsFire, and Crashlytics have announced offerings which they claim will replace UDIDs in a way which will pass Apple review.   You may have to present the user with a notice that an identifying number is being collected from their device, though, for privacy reasons.

I’m sure I haven’t covered everything here.  There are likely many other UDID problems I didn’t think of, and different approaches that I’ve presented to solve them.  I’d love to here your feedback.  What problems are you seeing with the transition away from UDIDs and what are you doing to solve them?