Our team gets asked quite a bit internally and externally about nuances regarding how iOS’s identifiers work. We figured we would push that  conversation to a blog post to reference and get some feedback on.


  • IDFA stands for “identifier for advertisers.” It’s a random, anonymous number that is assigned to a user and their device. It is temporary and can be blocked, like a cookie.


  • Every iOS device comes with a Unique Device Identifier (UDID). Until recently, the UDID allowed developers and marketers to track activity on the device, such as app purchases. With the release of iOS6, the UDID has been replaced with the Identifier for Advertising (IDFA).


  • The industry’s biggest leap toward mobile user data regulation came in March of 2012 when Apple began to deny developers access to UDIDs, forcing app creators to update their programs to leverage a new and far safer mobile data set called IDentifier For Advertisers, or IDFA, which was launched in conjunction with iOS6. Unlike its predecessor, the IDFA is not permanently tied to a mobile device, as users can reset their IDFA at any time for added security or opt out of ad tracking altogether with a setting aptly named, “Limit Ad Tracking.” As a result, the IDFA can no longer be easily linked to specific devices/users. This is similar to clearing cookies and changing privacy settings in your desktop browser. The data previously available with UDID is still available, but now in a “depersonalized” state.


  • ASIdentifierManager is the official way to garner the Advertising Identification Number from a device running iOS 6+. You can use -[[ASIdentifierManager sharedManager] advertisingIdentifier]; to get it. Returns an NSUUID.


  • In iOS 7 iPhone settings have been reorganized so that it will be easier for users to switch off the tracking: in iOS 6 the option was under “General”, in iOS 7 is under “Privacy” and “Advertising”.


  • advertisingIdentifier(aI)

Per the documentation, this is a read-only, alphanumeric string unique to each device, used for advertising only.

The value is constant for all third parties, but the ID can be deleted “if the user erases the device.”

  • identiferForVendor (idV)

Per the documentation, this is a read-only, alphanumeric string that uniquely identifies a device to the app developer.

The value is the same for apps that come from the same app developer running on the same device.


  • The documentation for the identifierForVendor says this. > The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors, and for apps on different devices regardless of vendor.

The question I had after reading that was, “what’s a vendor?” My first thought was that a vendor was defined as an Apple Developer Account. That turned out to be dead wrong. Next I thought it might it have to do with the AppIdentifierPrefix; similar to how Keychain Access can be shared between apps. Also dead wrong. It turns out to be very simple. A Vendor is defined by the first two parts of the reverse DNS formatted CFBundleIdentifier. For example com.doubleencore.app1 and com.doubleencore.app2 would be able to get the same identifierForVendor since they share the same com.doubleencore part of the CFBundleIdentifier. But com.massivelyoverrated or even net.doubleencore would get a completely different identifierForVendor.

The other thing to point out here is that if a user uninstalls all of the apps from a vendor and then re-installs them, the identifierForVendor will be reset.



  • Although cookies in iOS use the same mechanism as in Mac desktop OS (the NSHTTPCookieStorage class), they are explictly NOT shareable across apps in iOS, as this manual page states:


Additionally, Safari expicitly blocks third-party cookies; in general, it appears Apple is discouraging their use:


  • Some app developers are “hacking” the limitation of cookies vs IDFA (with one web-only and the other app-only) by having their (native) app call out to mobile Safari to get cookie info; this is definitely sub-optimal and likely not advisable; the second article indicates that Apple will reject apps from the App Store that try to do this:



  • The mobile cookie bears more than a passing resemblance to its desktop cousin: it’s a retrievable token or ID that’s dropped in HTML5 local storage. However, on iOS and Android, cookies are “sandboxed”; they can be used in the browser, but they’re walled off from apps. An app can employ a cookie by briefly opening and closing a browser window, but the information stored remains solely in that specific app’s purview:


Let us know if you have any questions or comments on this information!

Leave a Reply