ATT iOS: what it is, tracking request mechanism and IDFA

What is ATT (App Tracking Transparency)?

App Tracking Transparency is an Apple framework designed to protect user privacy, introduced in iOS 14.5. It requires apps to obtain explicit permission to access the device’s advertising identifier (IDFA) before using it for tracking.

Before ATT, developers could read the IDFA without asking, allowing ad networks to build user profiles and track activity across apps and websites. Apple considered this a violation of privacy and introduced a mandatory consent dialog.

The framework has been available since iOS 14.0, but became mandatory for all apps using IDFA with the release of iOS 14.5 in April 2021. According to Flurry Analytics, after ATT was implemented, fewer than 25% of US users consented to tracking, which fundamentally changed the mobile advertising market.

ATT checks for permission through a special system dialog that the app cannot modify or bypass. The user sees a standard popup with text provided by the developer and chooses either “Allow” or “Ask App Not to Track.”

How ATT relates to iOS privacy

Apple positions ATT as part of its overall privacy strategy, which also includes Privacy Nutrition Labels in the App Store and the Privacy Manifest. All three mechanisms work together: labels show what data the app collects, the Manifest declares the reasons for using APIs, and ATT gives the user control over tracking.

Refusing tracking does not block the app itself — users can continue using all features, but ad networks will not receive the IDFA for personalization and attribution. Apple’s alternatives to IDFA include SKAdNetwork and Probabilistic Attribution.

According to Branch Metrics, after ATT was introduced, the share of apps receiving IDFA dropped from 70% to 20% globally. This led to a fundamental rethinking of install attribution and ad monetization approaches.

Changes in iOS 15 and 16

In iOS 15, Apple did not tighten ATT requirements but added App Privacy Report — a report showing users how often apps access sensors and data. iOS 16 expanded control: users can change their tracking settings at any time via Settings → Privacy → Tracking.

Importantly, if a user selects “Ask App Not to Track” in the ATT dialog, the app does not receive the IDFA value — instead, it returns a string of zeros: 00000000-0000-0000-0000-000000000000. Attempting to read IDFA through other means or workarounds will result in app rejection from the App Store.

Starting with iOS 17, Apple strengthened enforcement: if an app requests IDFA without displaying the ATT system dialog, it receives a refusal at the OS level rather than just an empty identifier. This eliminates the possibility of background IDFA collection without user knowledge.

How the tracking request works in iOS

The ATT request process consists of three stages: checking the status, displaying the system dialog, and processing the response. The developer cannot skip any step — the OS controls each stage.

Checking authorization status

Before calling the dialog, the app must check the current status via ATTrackingManager. The possible statuses are: notDetermined (not yet requested), restricted (prohibited by device policies), denied (user refused), authorized (allowed).

If the status is already determined (authorized or denied), the dialog cannot be called again — the user has made a permanent choice. The only way to change it is through iOS system settings.

The status is checked using the ATTrackingManager.trackingAuthorizationStatus property. The call must happen on the main thread since the system dialog is a UI component.

import AppTrackingTransparency
import AdSupport

func checkTrackingStatus() {
    let status = ATTrackingManager.trackingAuthorizationStatus
    switch status {
    case .notDetermined:
        requestTrackingPermission()
    case .authorized:
        readIDFA()
    case .denied, .restricted:
        useAlternativeTracking()
    @unknown default:
        break
    }
}

Displaying the system dialog

To show the dialog, call the requestTrackingAuthorization method with a closure that receives the user’s choice. Important: the dialog appears only once. If the developer tries to call it again, the system ignores the request.

The dialog text consists of two parts: a system header (which cannot be changed) and a custom message that the developer specifies in Info.plist under the NSUserTrackingUsageDescription key.

The dialog should appear in a natural context — not immediately at app launch, but at the first attempt to use tracking-related functionality. Apple recommends showing the dialog after the user understands the value of the feature.

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        DispatchQueue.main.async {
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier
                print("IDFA: \(idfa)")
            case .denied:
                print("User denied tracking")
            default:
                break
            }
        }
    }
}

IDFA and access restrictions

IDFA (Identifier for Advertisers) is a unique advertising identifier for iOS devices, used for targeted advertising and install attribution. Before ATT, developers obtained it through ASIdentifierManager without restrictions. After ATT, access to IDFA is blocked until the user gives explicit consent.

What IDFA is and why it is needed

IDFA is a UUID string unique to each iOS device. Ad networks use IDFA for: tracking app installs (attribution), showing relevant ads based on user interests, measuring ad campaign effectiveness, and retargeting — bringing back users who did not complete a desired action.

After a user denies tracking, ASIdentifierManager returns the value 00000000-0000-0000-0000-000000000000. The app can still read IDFA for technical purposes (such as anti-fraud) but cannot pass it to ad networks.

According to Singular (2024), the global ATT consent rate is 25–35%, with Europe (GDPR) showing higher rates (40–50%) than the US (15–25%). This pushed ad platforms to develop alternative attribution methods.

Alternatives to IDFA: SKAdNetwork and Probabilistic Attribution

SKAdNetwork is an Apple framework for install attribution without exposing IDFA. It works at the OS level: the ad network sends a signed postback, which Apple validates and forwards to the developer. Attribution happens without identifying a specific user — only at the campaign level.

Probabilistic Attribution uses multiple device signals — model, iOS version, time zone, screen brightness — to probabilistically match installs to ad impressions. However, Apple prohibits this method in its guidelines, and its use may lead to app rejection.

Google, Adjust, and AppsFlyer have developed their own hybrid solutions that combine SKAdNetwork with proprietary aggregated data. For example, Google Ads Conversion Tracking uses SKAdNetwork postbacks and its own machine learning models for attribution without IDFA.

Implementing ATT in app code

To integrate ATT, you need to add the NSUserTrackingUsageDescription key to Info.plist and import the AppTrackingTransparency framework. Below are steps for Swift and Objective-C.

Setting up Info.plist

The first step is to add the NSUserTrackingUsageDescription key to Info.plist with text explaining why the app needs tracking. This text will appear in the system dialog. Example: “Your IDFA is used to show personalized ads and track campaign effectiveness.”

Without this key, calling requestTrackingAuthorization will cause a crash — Apple explicitly checks for NSUserTrackingUsageDescription before showing the dialog. The text should be concise, specific, and reflect actual data usage.

Important: the key is added manually via Xcode Info tab or by editing the XML source of Info.plist. After adding it, rebuild the project and verify that the key appears in the final binary.

<!-- Info.plist -->
<key>NSUserTrackingUsageDescription</key>
<string>This identifier is used to deliver
personalized ads and measure campaign performance.</string>

Full Swift integration

In a real project, it is best to call the ATT request before the first launch of an ad module or tracker. It is recommended to first explain the value of consent on a separate screen (pre-permission prompt) — this increases consent rates by 20–30%.

A pre-permission prompt is a custom UI that shows the benefit of enabling tracking (“Help us show you relevant ads”). Only after tapping “Continue” does the system ATT dialog appear. Adjust (2024) recorded a 40% increase in consent when using a pre-permission screen.

final class TrackingManager {
    static let shared = TrackingManager()

    func requestTrackingIfNeeded() {
        guard ATTrackingManager.trackingAuthorizationStatus
            == .notDetermined
        else { return }

        ATTrackingManager.requestTrackingAuthorization { _ in
            NotificationCenter.default.post(
                Notification(Name("trackingStatusChanged"))
            )
        }
    }
}

Common ATT mistakes

Developers often make typical mistakes when integrating ATT, which lead to lower consent conversion or app rejection by App Store reviewers. Let’s examine the five most common problems.

Requesting ATT immediately after app launch

The most common mistake is showing the ATT system dialog on the very first screen right after the app loads. The user does not yet understand the app’s value and is likely to tap “Deny.” IronSource (2023) showed a 32% drop in consent when requesting on the first screen compared to after the third session.

Recommendation: request tracking after the user has performed a valuable action (viewed content, started onboarding) or after 3–5 app sessions. This increases trust and perceived value.

Missing pre-permission screen

Showing the ATT system dialog without prior explanation is a mistake that drops conversion to 15–20%. The user sees an unexpected request and instinctively declines. A pre-permission screen explaining the benefit raises consent to 35–45%.

The pre-permission text should be specific: “Allow us to show relevant ads — this helps us stay free.” Avoid vague phrases — they lower trust. GameAnalytics showed in 2023 that a pre-permission screen explaining the benefit yields 28% more consents than a blank screen.

Ignoring restricted and denied status

If the user has already denied tracking or the status is restricted (parental controls, corporate policies), the app must not call the ATT dialog again. A repeated call will not work and is perceived as a privacy violation. Instead, switch to SKAdNetwork and contextual advertising.

In restricted status, the app cannot determine whether the “Allow Tracking Requests” option is enabled in settings. In this case, always use SKAdNetwork as the sole attribution method and do not show a pre-permission screen.

Reading IDFA without calling ATT

Reading IDFA via ASIdentifierManager.shared().advertisingIdentifier without prior ATT permission returns a string of zeros. Some developers try to use old methods of accessing IDFA through private APIs — this guarantees rejection during app review.

Apple uses static code analysis and machine learning to detect workarounds. Even if the app passes review, subsequent updates or automated checks may reveal the violation and lead to a developer account ban.

Incorrect NSUserTrackingUsageDescription text

A text that is too long, vague, or misleading in the NSUserTrackingUsageDescription key is grounds for rejection by reviewers. Apple checks that the description matches the actual data usage. If the app has no ads but states “for advertising purposes,” the reviewer will reject the build.

Recommended format: a specific description of the purpose of IDFA usage, 2–3 sentences long. Example for an app without ads: “The identifier is used for analytics and fraud prevention. Data is not shared with third parties and is not used for profiling.”