Apple Ads Attribution API: A Current Implementation Guide

Apple’s current API for Apple Ads attribution combines an on-device token from the AdServices framework with a server-side request to Apple. It is the right integration for Apple Ads campaigns on iOS 14.3 and later.

Do not build new work on ADClient or the old iAd attribution API. Apple documents that legacy requests return attribution=false or errors; AdServices is the current integration.

The important distinction is simple: AdServices tells you whether Apple matched this install to an Apple Ads campaign. Your product analytics tells you whether that installed person became an activated customer.

The current architecture

The flow has four parts:

1. The iOS app requests an attribution token from AAAttribution.
2. The app sends that token to your server over HTTPS.
3. The server posts the token to Apple’s attribution endpoint.
4. The server stores only the useful, normalized attribution fields against the anonymous install or first-session identifier.

Apple’s AdServices documentation describes this split directly. Keeping the Apple request on your server makes retry handling, auditing, and campaign joins much simpler. It also avoids putting reporting credentials or business logic in the binary.

Request the token at first launch

At application startup, generate a token and deliver it to a server endpoint. Keep this off the critical path for showing the first screen.

import AdServices

func sendAppleAdsToken() {
    do {
        let token = try AAAttribution.attributionToken()
        Task {
            await attributionAPI.submit(token: token)
        }
    } catch {
        // Log an operational error without blocking the app experience.
    }
}

The token has a 24-hour lifetime. Apple also generates a new token when the person’s App Tracking Transparency status changes, so do not assume a token is immutable app state. Use the result of the server request as the durable record, not the token itself.

Handle 404 correctly

The most common implementation mistake is treating a 404 as a permanent failure. Apple notes that a valid token can return 404 when the request happens too quickly after generation. Its recommendation is a five-second retry interval with no more than three attempts.

That leads to a compact server policy:

The response can be standard or detailed depending on the person’s ATT state. Build reporting that works with the fields you are allowed to receive, rather than assuming a detailed response will always be available.

Join IDs to campaign reporting

An attributed response can contain IDs such as adGroupId, campaignId, keywordId, and adId, depending on the response and device context. IDs are useful for reliable joins, but they are not useful labels for a product manager deciding where to spend tomorrow.

Sync Apple Ads campaign reporting separately, then resolve those IDs to campaign and ad-group names. Do this server-side so historical journeys are not tied to whatever a campaign happened to be named at the moment an app opened.

Keep attribution and onboarding as separate layers

Apple Ads attribution answers acquisition questions. A funnel answers product questions. Joining the two gives a team a useful decision table:

Apple Ads attribution is not SKAdNetwork

Apple Ads attribution is an Apple Ads-specific workflow with a direct campaign record. SKAdNetwork and AdAttributionKit serve broader privacy-preserving ad measurement across registered advertising networks and have delayed, aggregated-style postbacks. They answer different questions and should not be forced into one report.

Use Apple Ads attribution when you need to evaluate Apple Ads campaigns and keywords. Use SKAdNetwork and AdAttributionKit when you need to understand the postback-based measurement model used by broader iOS advertising.

For the product side of the loop, see Apple Search Ads keyword analytics and mobile app conversion tracking.