IDFV

Definition

The IDFV, or Identifier for Vendor, is a UUID that iOS gives an app to identify the device it is running on, scoped so that every app from the same vendor receives the same value and apps from any other vendor receive a different one.

The IDFV is the identifier people reach for when ATT denies them the IDFA, and it is the wrong tool for that job — not because using it is prohibited, but because its scope makes the click-to-install join arithmetically impossible. It is genuinely useful for something else: recognising the same device across your own portfolio with no permission prompt at all. The two facts that catch teams out are that it can legitimately return nil, and that it is per-device rather than per-user.

Reading it, and the nil you have to handle

import UIKit

/// Returns the IDFV, or nil if iOS cannot supply one yet.
///
/// Apple documents exactly one case where a valid installation gets nil:
/// the device has been restarted and not yet unlocked. The value becomes
/// available after first unlock, so this must not be cached as "no IDFV".
func vendorIdentifier() -> UUID? {
    return UIDevice.current.identifierForVendor
}

/// What most code actually wants: a value, or a retry.
func vendorIdentifierWhenReady(completion: @escaping (UUID) -> Void) {
    if let id = UIDevice.current.identifierForVendor {
        completion(id)
        return
    }
    // Pre-first-unlock. A background launch can land here.
    NotificationCenter.default.addObserver(
        forName: UIApplication.protectedDataDidBecomeAvailableNotification,
        object: nil,
        queue: .main
    ) { _ in
        if let id = UIDevice.current.identifierForVendor {
            completion(id)
        }
    }
}

No permission prompt is involved. The IDFV is available whatever the user answered to App Tracking Transparency, because ATT governs tracking a user across apps and websites owned by *other* companies, and the IDFV cannot do that by construction. This is the whole reason it is useful and the whole reason it cannot replace the IDFA.

What "vendor" means, precisely

Vendor is not your Apple Developer account in the general case. For an app installed from the App Store, Apple derives the vendor from App Store data. For anything else — a development build, TestFlight in some configurations, an enterprise distribution — it is computed from the bundle identifier: the first two components of a reverse-DNS bundle ID, or the entire bundle ID if it has fewer than three components.

The consequence for App Clips is useful: a clip whose bundle ID sits under the same two leading components as the full app reads the same IDFV, which gives you a permission-free way to recognise that the clip and the app are on one device. The consequence for attribution is fatal: the publisher app that showed the ad has a different vendor prefix, so it computes a different UUID for the same hardware, and there is nothing to join on.

What it can be used for, and the Android analogue

The IDFV answers one question well: is this the same device as before, within my own apps, without asking anyone's permission. That covers install deduplication, device-scoped session and crash grouping, abuse and multi-account detection, and carrying state between a clip and its full app. It does not answer who the user is — one person with an iPhone and an iPad has two IDFVs, which is why cross-device attribution needs a login identity rather than any device identifier.

The App Set ID is the closest Android equivalent and the comparison is worth internalising, because the two differ in a way that breaks naive cross-platform code: the App Set ID can expire on a timer even if nothing is uninstalled, and Google's policy forbids using it for advertising measurement or personalisation at all. The IDFV has no timer and no equivalent prohibition — it simply cannot reach across vendors, so the prohibition is unnecessary.

For deep linking the IDFV is a supporting signal, never the mechanism. Routing an installed app comes from the Universal Link payload, and matching a deferred deep link comes from a first-party click identifier you generated and can recognise. If a vendor proposes the IDFV as the way they will match your installs after an ATT denial, ask them to explain how their SDK inside a publisher app reads your vendor's UUID. It cannot, and the answer will tell you what they are really doing — see fingerprint attribution for the technique that question usually uncovers.