Our push notifications only reach users that have opted in to receive push, and the ability to opt in or out is important. We think that eliminating the ability to identify users automatically via their device identifiers is the right thing to do. Privacy really matters to app users, and we want our developer community to be able to honor users’ privacy concerns with tools that follow the latest best practices.
Q: Why have you removed UDID from the iOS device library?
A: Apple has deprecated the usage of UDID's inside apps, and has begun rejecting apps that contain a reference to that specific API. Since our library is embedded within developer's apps, we want to make sure that they won't be rejected. The UDID is not required by Urban Airship, so we've simply removed it from our library to comply with this new best practice.
Q: What exactly are you tracking within iOS apps now that UDID is gone?
A: Urban Airship has a User ID that has been in our library for more than a year. This identifier is used to correlate multiple app installations to a single person. For example you may have Subscription content on an iPhone and an iPad, so this identifier is used to bridge those together in order to give you access to content in both places. This bridging is done through our email restore flow, or using the automatic restore flow for Auto-Renewables purchases. We've also added a new identifier that tracks unique app installations in place of the UDID. This new application identifier does not track devices.
Q: Is Apple ok with the change you are making?
A: The application specific identifier that we're switching to uses Apple's recommended route of a CFUUID (a confusingly similar name, but a different method altogether). It is unique, but only usable by Urban Airship and will not track a device, only an app installation. We use the Application Bundle's keychain to persist this identifier as well as our own User ID where possible, but device restores and upgrades can cause new identifiers to be created in some cases.
Q: I used UDID to look up support requests for Subscriptions users. What do I do now that it's gone?
A: We're providing sample code (a Settings.bundle) that allows you to expose the User ID in the Settings App on the phone. If an app user contacts you about a support item, have them look up that ID in their iOS device Settings, under your app, and provide it to you. You will be able to lookup their transaction history with this ID, just like you could with UDID. You will need to submit an app update to add this functionality.
Q: What about OpenUDID or SecureUDID? Have you considered using those?
A: We are watching the industry trends to see what emerges. In the end, users should have control over access to device identifiers by apps.
Q: What are you going to do with all the UDID data you have stored?
A: All UDID data in our system is stored in a hashed format for privacy concerns. As apps upgrade to the latest version of our library, the old UDID will be overwritten with the new application specific identifier in most instances. Some systems (like Reports) will continue to contain historical hashed UDID's for continuity purposes, however that data will also expire over time. Typical upgrade cycles can last as long as 12 months and in some cases longer, so there may be residual hashed UDID's stored for an equivalent period.