iOS has no install referrer. It has three other things.

Is there an install referrer API on iOS?

The Play Install Referrer API is an interface exposed by the Google Play Store app that lets an installed Android app ask which referrer string was attached to the click that installed it. Google documents it as returning the referrer URL, the referrer click timestamp, the installation begin timestamp and the app version at first install. It is one call, it happens inside your app, and it answers the question where did this specific install come from.

iOS has nothing shaped like that. Not a differently-named version of it — no equivalent at all. The App Store does not hand the installed app a string describing the click that produced it.

That absence is deliberate rather than an oversight, and it is why the question splits into three the moment you cross platforms. Each row below is a different question, and the answers are not interchangeable.

The rows are not interchangeable, and most of the confusion comes from asking the first question and being handed an answer to the second.

What do App Store campaign links actually report?

An App Store product URL accepts three parameters, and Apple documents each of them.

• pt — the provider token. It identifies your developer account and stays identical across every campaign you ever run. You do not request it: it is generated the first time you create a campaign link in App Store Connect.
• ct — the campaign token. One per campaign, up to 30 alphanumeric characters.
• mt — the media type token.

A tagged URL looks like https://apps.apple.com/app/apple-store/id123456789?pt=123456&ct=test1234&mt=8.

This is the closest thing iOS has to the intent behind install referrer, and the important property is where the answer arrives: App Store Connect → Analytics → Acquisition → Campaigns. Not in your app. There is no API that reads it back out, and no SDK that surfaces it — the number lives in the console and stays there.

That has a consequence worth stating plainly, because it is the reason a lot of teams conclude the tagging “did not work”: campaign links tell you how many installs a campaign produced. They do not tell you which install belonged to which click. If your question is the second one, this system will never answer it no matter how carefully you tag.

Three limits decide whether the number appears at all, and all three are Apple’s own, published on the page linked above.

1. A campaign takes at least 24 hours to appear in Analytics after launch.
2. Data appears only once at least five individual users have produced first-time downloads from it. Below that threshold the row is suppressed, not zero.
3. The download has to happen within 24 hours of the click to count as a First-Time Download against that campaign.

A campaign that ran for two days at low volume can therefore be working perfectly and reporting nothing. The full checklist for a campaign that is not showing up covers what to check before assuming the link is at fault.

What do AdServices and AdAttributionKit cover?

These are Apple’s ad-attribution frameworks, and they are what people are usually pointed at when they ask for an install referrer.

AdServices returns an attribution token from inside your app, which you exchange with Apple for an attribution payload. It covers Apple Ads — that is, ads bought on the App Store itself. It does not describe a click on your own bio link, your newsletter, or a partner’s post.

AdAttributionKit is the framework Apple introduced to build on SKAdNetwork’s foundations, reporting ad-driven conversions on a deliberate delay and with deliberate coarseness, so that the report cannot be resolved back to a person.

Both are real answers to the second row of the table. Neither is a referrer string, and neither works for the case that brought most people here: an ordinary link you published yourself, on a channel you control.

What does iOS genuinely not do?

If the question is which user installed from which invite — a referral code, a shared link, a specific piece of content — then no store-level mechanism on iOS answers it, and none on Android answers it reliably either. That job is deferred deep linking, and it needs a payload that survives the install. Carrying a payload across an install is install attribution, and install attribution needs an SDK inside your app.

That is the honest boundary, and it is where a link tool stops being the right shape of product. If you need it, a mobile measurement platform is the correct answer — and you can put a link in front of one rather than choosing between them.

What should a link you publish today carry?

If you publish one address and expect both stores to report on it, the address has to carry both platforms’ parameters, because neither store reads the other’s. Play wants a URL-encoded referrer string carrying UTM fields; the App Store wants ct, pt and mt. A link carrying only UTM parameters is untagged on iOS. A link carrying only ct/pt is untagged on Play.

An AppIn link composes both at the moment of the tap, from the campaign set on the link — the Apple ct and the Play referrer. The Apple provider token is yours: you paste your pt in once and it travels with every click afterwards. We cannot invent that number, and a tool that claimed to would be sending Apple a value that means nothing.

Nothing about this goes into your app, which is the point — and also the limit. What the parameters are and how they are composed covers the mechanics; the Play side has its own reader problem worth reading before you tag anything for Android.

Questions

Is there an install referrer API on iOS?

No. Android's Play Install Referrer API has no iOS counterpart. iOS carries campaign context in App Store campaign links, which are read in App Store Connect Analytics rather than by your app, and handles ad attribution separately through AdServices and AdAttributionKit.

Can my iOS app read which campaign installed it?

Not from the App Store. Campaign link data stays inside App Store Connect Analytics and is not exposed to the installed app. AdServices returns an attribution token for Apple Ads, and AdAttributionKit reports conversions on a privacy-preserving delay — neither is a general referrer string.

What is the iOS equivalent of utm_source on a Play link?

The campaign token, ct, on an App Store product URL, paired with your provider token, pt. It is one campaign identifier rather than a set of UTM fields, and it is capped at 30 characters.

Why does the same link work differently on Android and iOS?

Because the two stores read different parameters. Play accepts a URL-encoded referrer string carrying UTM fields; the App Store accepts ct, pt and mt. A link that carries only one of the two is untagged on the other platform.