Deeplinkly

Glossary/iOS platform and privacy

IDFA

Definition

The IDFA, or Identifier for Advertisers, is a resettable per-device UUID that iOS provides to apps for advertising measurement, and which is only readable when the user has granted App Tracking Transparency permission.

For most of the last decade the IDFA was mobile attribution: an ad network recorded it on the click, the app reported it on the install, and matching the two gave you a deterministic answer. ATT ended that as a default in iOS 14.5. The identifier still exists and still works exactly as it used to — for the minority of users who allow it.

Reading it, and what you get when you cannot

The complete code path
import AdSupport
import AppTrackingTransparency

func advertisingIdentifier() -> UUID? {
    // Reading without authorisation is not an error — it returns
    // the all-zero UUID, which is why unguarded code ships a
    // constant identifier for every unauthorised device.
    guard ATTrackingManager.trackingAuthorizationStatus == .authorized else {
        return nil
    }
    let idfa = ASIdentifierManager.shared().advertisingIdentifier
    return idfa.uuidString == "00000000-0000-0000-0000-000000000000"
        ? nil
        : idfa
}

The zeroed UUID is the bug that hides in plain sight

00000000-0000-0000-0000-000000000000 is returned rather than nil, so a pipeline that does not check it treats every non-consenting device as the same user. The symptom is one "device" with implausible session counts, and an attribution join that appears to work while matching everyone to everyone.

What the identifier returns in each state.
ATT statusadvertisingIdentifierUsable for attribution
.authorizedA real, stable UUIDYes
.deniedAll zerosNo
.notDeterminedAll zerosNo
.restrictedAll zerosNo

isAdvertisingTrackingEnabled was the pre-iOS-14 way to check this and is deprecated; on modern iOS it reports the ATT status rather than the old per-device Limit Ad Tracking toggle. New code should read trackingAuthorizationStatus and treat the zero check as a belt-and-braces guard.

IDFA, IDFV and vendor scope

iOS exposes a second identifier that is frequently mistaken for a fallback. It is not one — its scope is deliberately incompatible with attribution.

IDFA compared with IDFV.
IDFAIDFV
ScopeThe whole device, across all appsYour apps only, per device
Needs ATT permissionYesNo
Stable across your appsYesYes
Visible to an ad networkYes, if authorisedNo — different value in their app
Resets whenThe user resets it in SettingsAll your apps are uninstalled
Useful for ad attributionYesNo

The IDFV is genuinely useful for linking a user across your own portfolio without consent, and useless for the click-to-install join, because the publisher app computes a different IDFV for the same device. Anyone proposing the IDFV as an ATT workaround has not tested it across two vendors.

Resets are user-initiated and total

A user can reset the IDFA in Settings at any time, producing a brand-new UUID with no link to the old one. Any long-window analysis keyed on the IDFA will show those devices as churned and re-acquired, which is one reason IDFA-keyed retention was overstating churn even before ATT.

What you use instead

The honest framing is that no single replacement exists, because the IDFA's value was precisely that it was one identifier visible to everyone. What replaced it is a set of narrower signals, each valid in a different situation.

Post-IDFA signals and what each one can answer.
SignalAnswersRequires consent
SKAdNetworkWhich campaign drove installs, in aggregateNo
AdAttributionKitThe same, plus re-engagementNo
First-party click ID in the linkWhich of *your* links drove this sessionNo
Universal Link payloadDeterministic routing and context for an installed appNo
IDFADeterministic device-level matchYes
Device fingerprintingNothing you may useProhibited

For deep linking specifically, the IDFA was never the important part. A deferred deep link can be matched from a first-party click identifier you control, and routing an installed app is handled by the link itself. The measurement question — which paid campaign deserves credit — is the part that genuinely lost its deterministic answer, and Apple's frameworks are the sanctioned substitute.

We do not ship fingerprinting to fill the gap. It violates Apple's rules regardless of ATT status, and the accuracy claims made for it are not verifiable by the advertiser paying for them — see why installs go unattributed for what we report instead.

iOS SDK documentation

Our iOS SDK does not read the IDFA unless your app has authorisation and asks it to. The documentation covers exactly which signals it uses for deferred matching instead, so you can see what the attribution depends on.

Open the ios sdk documentation

Frequently asked questions

What is the IDFA?
The IDFA, or Identifier for Advertisers, is a resettable UUID that identifies an iOS device for advertising measurement. It is shared across every app on the device, which is what made it usable for matching an ad click in one app to an install in another, and since iOS 14.5 it is only readable by apps that have been granted App Tracking Transparency permission.
What does iOS return if the IDFA is unavailable?
It returns the all-zero UUID 00000000-0000-0000-0000-000000000000 rather than nil or an error. Code that does not explicitly check for this treats every non-consenting device as one shared identity, which produces a single implausibly active device in analytics and silently corrupts any attribution join built on the value.
What is the difference between the IDFA and the IDFV?
The IDFA is device-wide and visible to every app that has ATT permission; the IDFV is scoped to one vendor, so your apps see a consistent value but another company's app sees a completely different one for the same device. That makes the IDFV useful for linking users across your own portfolio and useless for ad attribution, since the publisher and advertiser cannot compare values.
Can users reset their IDFA?
Yes, at any time in Settings, and the reset produces an entirely new UUID with no link to the previous one. Any measurement keyed on the IDFA will therefore show a reset device as a churned user and a new acquisition, which inflated churn and new-user counts even before App Tracking Transparency reduced availability.
What replaced the IDFA for attribution?
No single identifier did. Campaign-level install measurement moved to SKAdNetwork and AdAttributionKit, which report in aggregate without any cross-app identifier; routing and deep link context come from the link payload itself; and first-party click identifiers you control handle deferred matching. Device fingerprinting is not a permitted substitute regardless of consent status.

Related terms

  • App Tracking Transparency (ATT)App Tracking Transparency is the iOS framework that requires an app to obtain explicit user permission before accessing the device's advertising identifier or otherwise tracking that user across apps and websites owned by other companies.
  • SKAdNetworkSKAdNetwork is Apple's StoreKit framework that attributes app installs to advertising campaigns without exposing a device identifier, by having the operating system send a delayed, aggregated postback to the ad network that won the install.
  • Unattributed installsAn install is unattributed when no signal linking it to a prior ad click or link tap survived the journey through the app store, which can mean the install was organic or that the signal existed and was lost.
  • GAIDThe GAID, or Google Advertising ID, is a resettable per-device identifier that Android provides for advertising and analytics, and which is replaced by a string of zeros for users who opt out of ads personalisation.