AdAttributionKit vs SKAdNetwork: What Changes
AdAttributionKit doesn't replace SKAdNetwork so much as wrap it, extend it, and quietly move the interesting parts up a layer. If you already understand SKAN 4 postbacks and conversion values, most of AdAttributionKit will feel familiar. What's genuinely new is the stuff SKAN could never do: re-engagement attribution, web-to-app measurement, configurable windows, and support for app stores that aren't Apple's. The two run side by side today, and Apple has said they're interoperable, so this isn't a cutover you schedule for a Tuesday. It's a slow migration where you learn the new vocabulary while the old plumbing keeps running.
I've shipped attribution code through the SKAN 2, 3, and 4 transitions, and each one taught me the same lesson: read what the OS actually sends on-device, not what the marketing deck promises. So let me walk through what AdAttributionKit changes, concept by concept, and where the docs leave you guessing.
The one-paragraph history
AdAttributionKit shipped in March 2024 with iOS 17.4, according to Business of Apps. At launch it did roughly what SKAN did (install attribution on click or view, with a 24-hour view-through window), but it was built to grow. The re-engagement half arrived with iOS 18. Then WWDC 2025 and iOS 18.4 piled on the features that make it actually worth the migration effort: configurable windows, cooldowns, overlapping re-engagement, country codes in the postback. Adjust frames AAK plainly: it takes the SKAN model and adds re-engagement, multi-store coverage, and configurable windows, and the two frameworks are meant to coexist.
So nothing you built for SKAN is wasted. Your conversion-value encoding, your postback receiver, your crowd-anonymity assumptions, all of it carries over. AdAttributionKit is a superset, not a rewrite.
The concept-by-concept map
Here's the translation table I keep open when I'm reasoning about a migration. Left column is the SKAN 4 idea you already know; right column is what it becomes under AdAttributionKit.
| SKAN 4 concept | AdAttributionKit equivalent | What actually changed |
|---|---|---|
| Install (download) attribution | Install attribution | Same idea, same postback shape |
| Source identifier (2–4 digit hierarchical) | Source identifier | Carried over; still read it as nested hierarchy levels |
| Fine conversion value (6-bit, 64 values) | Conversion value | Unchanged encoding |
| Coarse value (none/low/medium/high) | Coarse value | Unchanged; still the crowd-anonymity fallback |
| Three postbacks, fixed windows (0–2, 3–7, 8–35 days) | Postbacks with configurable windows | You now set window lengths (iOS 18.4+) |
| No re-engagement | Re-engagement postbacks (click-only) | Brand-new capability |
| App Store installs only | App Store plus alternative marketplaces | marketplace identifier added |
| No cooldown control | Configurable attribution cooldown | New in iOS 18.4 |
| Country not in postback | Optional country code (crowd-anonymity gated) | New in iOS 18.4 |
| Web-to-app: awkward, mostly SKAN-adjacent | First-class web-to-app measurement | Supported natively |
Read that table and you can see the shape of it. The measurement primitives (conversion values, coarse buckets, postbacks, crowd anonymity) didn't move. What moved is control (you configure windows now) and coverage (re-engagement, web, other stores).
Conversion values: bring your existing encoding
SKAN 4's conversion values are the part teams sweat over, and the good news is they transfer intact. Per the Adjust help center, a fine conversion value is a 6-bit number, 64 possible states from 0 through 63, and when your install volume is too low to clear the anonymity threshold, Apple drops you to a coarse value of none, low, medium, or high instead. That degradation logic is identical in AdAttributionKit. If you already built a value schema that packs "day-1 revenue bucket plus a key event flag" into six bits, you don't touch it.
The three-postback structure carries too. SKAN 4 sends up to three postbacks for the winning attribution, and the windows are fixed by Apple at days 0–2, 3–7, and 8–35, so your measurement horizon tops out around 35 days. The difference under AAK is that iOS 18.4 lets you configure window lengths rather than accept Apple's fixed thirds. That sounds small. It isn't. A subscription app measuring a 30-day trial and a hyper-casual game measuring day-1 retention were both jammed into the same three buckets before. Now they don't have to be.
Re-engagement: the genuinely new thing
This is the headline. SKAN had no answer for "a user already has my app, did my ad bring them back?" AdAttributionKit does.
Re-engagement postbacks carry a conversionType key set to re-engagement, and per Aarki's FAQ they support the click interaction type only. There's no view-through re-engagement — a user has to actually tap. On the network side, an ad gets marked as re-engagement-eligible by setting eligible-for-re-engagement to true in the impression JSON. When a user who already has the app installed taps that ad, a universal link opens the app and drops them at the in-app destination the link specifies. If the app isn't installed, the same ad routes to the App Store as a normal install. One creative, two jobs.
Here's the on-device sequence, because this is where people get confused. The tap fires the universal link. The OS checks whether the advertised app is installed. Installed → re-engagement flow, app opens, and a postback with conversionType: re-engagement is eventually queued. Not installed → acquisition flow, App Store, standard install postback. The branching happens at tap time based on install state, not on anything you configure in the campaign.
The early re-engagement implementation had a real limitation: only one active re-engagement conversion per app. If a user touched two remarketing ads, only the last one counted. WWDC 2025 fixed that. Per Segwise's recap, iOS 18.4 introduced overlapping re-engagement windows plus conversion tags, so multiple re-engagement windows can coexist and you can tag which conversion belongs to which touch. If you run remarketing across several partners, that's the difference between usable data and a single-winner-takes-all mess.
Web-to-app, and the multi-store reality
SKAN was built for one world: an ad inside an app, an install from the App Store. AdAttributionKit was built for the messier one. It measures web-to-app journeys as a first-class case: a user sees your ad on the mobile web, ends up installing, and the attribution survives the hop. And because of the EU's Digital Markets Act, installs can now come from marketplaces that aren't Apple's, so AAK postbacks include a marketplace identifier telling you which store the install came from. If you don't distribute outside the App Store, you'll ignore that field. But it's there, and it signals where Apple thinks this is going.
What WWDC 2025 actually added
Singular's WWDC 2025 recap is the cleanest summary of the iOS 18.4 batch, and it's worth being precise about each item because a few change how you model campaigns:
Configurable attribution windows let you set the length instead of inheriting Apple's fixed 0–2 / 3–7 / 8–35 split. Configurable cooldowns let you block back-to-back conversions from competing for the same attribution, which cuts down the misattribution you get when a user converts twice in quick succession. Overlapping re-engagement windows and conversion tags, as covered above, unlock multi-touch remarketing. And postbacks can now include an optional country code, derived from the App Store, subject to crowd anonymity, so you only get geo once you clear the volume threshold.
The one I'd flag hardest for engineers is Development Postbacks. iOS 18.4 lets you configure and trigger a postback straight from the Settings app: simulate a conversion, set a custom conversion value and country code, fire it at your test endpoint. If you've ever tried to validate a SKAN receiver by waiting on real postbacks, you know why this matters. It turns a multi-day guessing game into a loop you can actually run.
The thing nobody tells you: timing is still a lie
I keep a running joke that postbacks arrive whenever they feel like it, and AdAttributionKit does nothing to retire it. The windows are configurable now, sure, but Apple still adds randomized delay before a postback lands, and the delay is deliberate — it's part of the privacy design, not a bug you can ticket. So the same discipline SKAN forced on you still applies: don't build dashboards that expect same-day attribution, and don't panic when day-2 numbers keep drifting up for a week.
One honestly-fuzzy area: the exact crowd-anonymity thresholds. The docs don't publish the numbers for when country codes or fine values appear, only the principle that more attributed volume unlocks more data. Testing is the only way to learn where your app sits, and where it sits changes as your volume changes. Plan for coarse-value fallbacks the same way you did under SKAN, because low-volume campaigns will still get the blurry version.
So do you migrate?
If you're a mobile marketer or an SDK engineer asking whether to adopt AdAttributionKit: yes, but treat it as additive. You keep SKAN running (Apple designed them to coexist, and the frameworks are interoperable) while you wire up the parts SKAN never gave you. In practice that means: turn on re-engagement measurement if you run remarketing, adopt configurable windows if your conversion horizon didn't fit Apple's fixed thirds, and use Development Postbacks to actually test the receiver instead of praying.
What you don't do is rip out working SKAN code because a new framework exists. The conversion values, the coarse fallbacks, the postback receiver, the crowd-anonymity math — that's all still load-bearing. AdAttributionKit is the same measurement engine with more dials and a couple of doors SKAN kept locked. Learn the dials, walk the on-device flow once with your own eyes, and migrate the pieces that buy you something.
For a deeper look at how re-engagement and universal links tie into deep-link routing, see our breakdown of deep-linking platforms compared. And if you're rebuilding measurement from scratch, the privacy-first attribution reference architecture covers where AAK and SKAN both fit.