AdAttributionKit vs SKAdNetwork: Interoperability Guide

AdAttributionKit vs SKAdNetwork is usually an interoperability and readiness decision, not an either-or cutover. Compare capabilities, run the six readiness gates, and protect reporting continuity.

If your team runs iOS app install or re-engagement campaigns, you have probably read that AdAttributionKit (AAK) "replaces" SKAdNetwork (SKAN), and that you should plan a cutover. Apple's own documentation says something more precise: AAK builds on SKAdNetwork, the two frameworks can coexist, and apps integrated with both should call both APIs (Apple, AdAttributionKit–SKAdNetwork interoperability). Apple's current SKAdNetwork documentation points developers toward AdAttributionKit for app ad campaigns, but it does not publish a shutdown date for SKAdNetwork (Apple, SKAdNetwork).

So the practical answer is: this is usually an interoperability and readiness decision, not an immediate either-or cutover. The work is to decide which framework serves which inventory, keep reporting continuous while both run, and avoid breaking the measurement your budget decisions already depend on. This guide gives you a comparison matrix, a six-gate readiness framework, a staged implementation workflow, and a diagnostic table for the mismatches you will hit. It covers only the AAK-versus-SKAN decision; for the broader attribution architecture — MMPs, product analytics, the transaction ledger, and incrementality experiments — see our mobile app attribution guide.

What each framework actually does

Both frameworks are Apple's privacy-preserving attribution systems for app advertising. Neither gives you user-level tracking, and neither is a substitute for your MMP, your product analytics, or your finance ledger.

SKAdNetwork is the established system. Ad networks register with Apple, sign impressions, and receive postbacks that attribute installs and, in later versions, support re-engagement and multiple postback windows with coarse and fine conversion values under privacy thresholds. It is the system most ad networks, MMPs, and reporting pipelines were built around.

AdAttributionKit, introduced at WWDC24, builds on SKAdNetwork and extends the model: it supports privacy-preserving attribution for installations and re-engagement, click-through and view-through attribution, custom creative, and JWS-signed impressions and postbacks (Apple, App AdAttributionKit; Apple, WWDC24 session 10060). It also documents conditional values and privacy thresholds, and it explicitly prohibits fingerprinting (Apple, App AdAttributionKit). One structural difference matters commercially: AAK's scope includes alternative app marketplaces in addition to the App Store, where those marketplaces operate, while SKAdNetwork is App Store-scoped (Apple, interoperability).

Neither framework restores deterministic, user-level journey data. Both deliver aggregated, thresholded, delayed signals. Treat any vendor slide promising otherwise with suspicion.

Comparison matrix

Dimension SKAdNetwork AdAttributionKit --------- Core job Privacy-preserving install and re-engagement attribution for App Store ads Privacy-preserving install and re-engagement attribution, building on SKAN Marketplace scope App Store App Store and alternative marketplaces where they operate Impression/postback handling Signed impressions; postbacks with coarse/fine conversion values under privacy thresholds JWS-signed impressions and postbacks; click-through and view-through attribution; custom creative support Re-engagement Supported in later SKAN versions Documented as a first-class capability Conversion-value continuity Established conversion-value schemas in most MMPs Conversion-value calls can bridge between the frameworks when both are integrated Implementation dependency Network registration, signed ads, app Info.plist entries, postback endpoints Same foundations, plus configuring both postback copy URLs when both frameworks are used What it cannot prove User-level journeys; causality; cross-channel incrementality The same — attribution credit is not incrementality

Sources: Apple, App AdAttributionKit; Apple, interoperability; Apple, WWDC24; Apple, configuring an advertised app.

Two rows deserve emphasis. First, conversion-value continuity: when an app is integrated with both frameworks, conversion-value update calls can bridge between them, which is the mechanism that keeps your value signals from resetting mid-transition (Apple, interoperability). Second, implementation dependency: when both frameworks are in play, Apple documents the need to configure both postback copy URLs and to coordinate the implementation (Apple, configuring an advertised app). This is an engineering coordination task, not a settings toggle.

How interoperability actually works

Apple's interoperability guidance is the load-bearing document for this decision, and it says four concrete things (Apple, interoperability):

The frameworks can coexist. An app can integrate both, and apps integrated with both should call both APIs.

Identifiers are compatible. An existing SKAdNetwork ad-network registration ID works with AdAttributionKit (Apple, registering an ad network).

Impressions from both frameworks are considered, and only one can win a conversion. You do not get double credit; you get a single winner across both systems.

Conversion-value calls can bridge. Value updates made through one framework can carry into the other's postback logic when both are integrated.

The commercial implication: running both is a documented, supported state — not a hack. The risk is not "running both"; the risk is running both uncoordinated, with postback endpoints, conversion-value schemas, and reporting dashboards that assume only one system exists.

The six-gate readiness framework

Treat each gate as a pass/fail decision with a named owner. Do not start engineering work until gates 1–3 are answered in writing.

Gate 1 — Business decision. What problem are you solving? Legitimate triggers: you need re-engagement measurement your current setup cannot deliver; you advertise into alternative marketplaces; a key network or MMP has shipped AAK support you want to use. Non-triggers: a blog post said SKAN is dead (Apple has published no shutdown date — Apple, SKAdNetwork), or a vendor wants a migration case study.

Gate 2 — OS and marketplace coverage. Which iOS versions do your paying users actually run, and which marketplaces do you sell through? AAK behavior is documented for stated OS versions and conditions; do not generalize beyond them (Apple, App AdAttributionKit). Pull your OS-version distribution from product analytics before scheduling anything.

Gate 3 — Ad-network and MMP support. Apple documents framework capabilities; it does not certify that your specific network or MMP supports every AAK feature. Ask each partner, in writing: which AAK features do you support today, for which campaign types, and how do your postbacks interoperate with SKAN during coexistence? Treat "we support AAK" as the start of the conversation, not the end.

Gate 4 — App configuration. Engineering scope: call both APIs if integrated with both, configure both postback copy URLs, and coordinate conversion-value bridging (Apple, interoperability; Apple, configuring an advertised app). Apple provides testing coverage for AAK flows (Apple, WWDC24) — budget for it.

Gate 5 — Reporting continuity. Define, before any release, how dashboards will read during coexistence: which source wins when both frameworks report the same conversion window, how conversion-value schema changes map onto existing cohort reporting, and who signs off that the numbers are comparable. This gate is where most migrations quietly fail — not in code, but in a quarter of unreadable trend lines.

Gate 6 — First-party value and reconciliation. Attribution postbacks are one input. Your transaction ledger, subscription state, and product analytics remain the sources of truth for revenue. Decide how AAK/SKAN-attributed conversions reconcile against first-party records, and keep that reconciliation rule stable across the transition so you can detect framework-induced drift rather than mistaking it for performance change.

A staged implementation workflow

Stage 0 — Pre-change baseline. Freeze a measurement baseline before touching anything: current postback volumes, install and re-engagement counts by network, conversion-value distribution, and the reconciliation delta between attributed conversions and first-party transactions. Annotate the baseline date in every dashboard.

Stage 1 — Dual-path test build. Ship the AAK integration behind a release you can roll back, with both frameworks calling their APIs as Apple documents. Validate in Apple's testing environment before production traffic touches it (Apple, WWDC24).

Stage 2 — Postback validation. Verify that postbacks arrive at both configured copy URLs, that JWS signatures validate, that only one framework wins each conversion as documented, and that conversion-value bridging behaves as designed (Apple, interoperability).

Stage 3 — Reconciliation. Compare attributed conversions against first-party transactions under the rule you set at Gate 6. Investigate structural breaks — a step-change that starts exactly at release — before accepting the new numbers.

Stage 4 — Release with annotations. Ship with release annotations in every reporting surface, a written rollback trigger (for example, postback loss or reconciliation breakage beyond your pre-agreed tolerance), and a monitoring window owned by a named person.

Stage 5 — Ongoing monitoring. Watch postback volume, winner distribution, and reconciliation delta for several conversion windows. SKAN and AAK postbacks are delayed; a quiet week is not proof of success or failure.

When not to migrate yet

Hold off when any of these is true:

Your measurement depends on a network or MMP that has not confirmed, in writing, which AAK features it supports for your campaign types.

You cannot staff the reporting-continuity work (Gate 5). A technically correct integration that scrambles your trend lines is a net loss.

You are mid-quarter on a budget decision that depends on comparable historical data. Sequence the change after the decision, or baseline explicitly.

Your only reason is industry chatter that SKAN is being switched off. Apple's current SKAdNetwork documentation points developers toward AAK for app ad campaigns but publishes no shutdown date (Apple, SKAdNetwork).

Anyone on the team proposes fingerprinting as a fallback for lost signal. Apple explicitly prohibits it (Apple, App AdAttributionKit), and it is a policy and platform risk, not a workaround.

The honest tradeoff: coexistence is supported but doubles the configuration surface you must validate and monitor. Migration is not free signal. Neither framework will improve ROAS, CAC, or conversion volume by itself; they change how credit is recorded, not what your product is worth to a user.

Diagnosing mismatches during coexistence

When numbers diverge after you enable both frameworks, work this table before blaming a partner:

Symptom Likely cause class First check --------- Total attributed installs drop at release Postback copy URL misconfiguration Both postback URLs configured and receiving (configuring an advertised app) One network shows zero AAK postbacks Partner support gap Written confirmation of that network's AAK feature support for your campaign type Conversion values look coarser than before Privacy thresholds / conditional values Threshold behavior documented by Apple; volume per campaign (App AdAttributionKit) Re-engagement appears in one framework only Impression eligibility differences Which framework's impressions were eligible and which won (interoperability) Attributed revenue diverges from ledger Reconciliation rule broken by schema change Gate 6 rule applied identically before and after release Dashboards double-count a conversion Reporting layer summing both frameworks Only one impression can win; verify your pipeline deduplicates across frameworks

Deliberately, there are no numeric tolerances in this table. The right tolerance depends on your volume, your privacy-threshold exposure, and your reconciliation history — inventing a universal percentage would be false precision.

Attribution credit is not incrementality

Both frameworks answer one question: which eligible ad impression wins credit for this conversion under Apple's rules. They do not answer whether the ad caused the conversion. A user who would have installed anyway and clicked an ad looks identical to a persuaded user in a postback.

Keep the layers separate in your planning documents: AAK/SKAN for platform attribution credit; your MMP for cross-network normalization; product analytics and the transaction ledger for what users actually did and paid; and holdout or geo experiments for causal lift. If you need the full architecture, our attribution-beyond-Meta guide covers how these layers fit together. Do not let a framework migration quietly redefine what "worked" means in your reporting.

Practical next step

If iOS attribution changes are blocking your channel allocation or re-engagement measurement, the useful next move is a readiness map, not a rewrite: which framework serves which inventory, which partners support what, which postback flows are validated, and which reconciliation rules protect your trend lines.

Sharply Labs works with mobile app teams on exactly this: we examine your decision map, current configurations, partner dependencies, postback flow, and reconciliation rules, and return a prioritized readiness plan. We do not promise migration, implementation completion, lower CAC, higher ROAS, or complete visibility — we promise a clear-eyed read on what is ready, what is not, and what to do in what order. See how we work with mobile app teams and our growth services, or start with the broader attribution architecture guide.

---