Glossary/iOS platform and privacy
App Clip
Definition
An App Clip is a lightweight portion of an iOS app that a user can launch from a URL, code, or NFC tag without installing the full app from the App Store.
For deep linking it is a strange and useful case: the App Clip is launched by a URL, so every invocation is a deep link by definition — and because it runs without an install, it sits in the middle of the fallback chain between a web page and a full app. It also has its own attribution rules, which almost no glossary covers and which quietly break assumptions carried over from full-app measurement.
How an App Clip is invoked
Every launch starts from a URL — the invocation URL — even when the user scanned a code or tapped a tag. That URL is registered as an App Clip Experience in App Store Connect and authorised by your domain's AASA file.
{
"appclips": {
"apps": ["A1B2C3D4E5.com.example.shop.Clip"]
},
"applinks": {
"details": [
{
"appIDs": ["A1B2C3D4E5.com.example.shop"],
"components": [{ "/": "/table/*" }]
}
]
}
}| Trigger | Requires | Notes |
|---|---|---|
| App Clip Code | A generated code, printed or on screen | Encodes the invocation URL; scannable by camera or NFC |
| NFC tag | A tag written with the invocation URL | Tap to launch, no camera |
| QR code | Any QR encoding the URL | Falls back to Safari on non-iOS devices |
| Safari smart banner | The apple-itunes-app meta tag with app-clip-bundle-id | The web-to-clip path |
| Messages | A shared link | The recipient sees the App Clip card |
| Maps place card | An Advanced App Clip Experience | Appears on the business's place card |
| Spotlight or Siri Suggestions | Prior use | System-surfaced |
The App Clip Card comes before your code
iOS shows a card with your image, title, subtitle and action button, configured per Experience in App Store Connect, and only downloads and runs the clip after the user taps. That card is a conversion step you do not control from code — its copy is set in the console, and it is where a meaningful share of invocations end.
Reading the invocation URL
The URL arrives the same way a Universal Link does — as an NSUserActivity — which means the routing code you already have mostly works. What differs is that for an App Clip this is the *only* entry point.
@main
struct ShopClip: App {
var body: some Scene {
WindowGroup {
ClipRootView()
.onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { activity in
guard let url = activity.webpageURL else { return }
// https://example.com/table/42?promo=spring
Router.shared.handle(url)
// Persist for the full app to pick up after an upgrade
if let shared = UserDefaults(suiteName: "group.com.example.shop") {
shared.set(url.absoluteString, forKey: "clipInvocationURL")
}
}
}
}
}Local testing does not require App Store Connect: set the _XCAppClipURL environment variable in the App Clip scheme and Xcode passes it as the invocation URL on launch.
# Xcode > Edit Scheme > Run > Arguments > Environment Variables
_XCAppClipURL = https://example.com/table/42?promo=spring
# Or on a booted simulator
xcrun simctl openurl booted "https://example.com/table/42?promo=spring"
# Confirm the appclips key is present in the served file
curl -sS https://example.com/.well-known/apple-app-site-association | \
python3 -m json.tool | grep -A 3 appclipsThe constraints
| App Clip | Full app | |
|---|---|---|
| Uncompressed size budget | 15 MB on iOS 16+ (10 MB before) | No practical limit |
| Installation required | No | Yes |
| Lifetime on device | Evicted after a period of disuse | Until deleted |
| Background execution | No | Yes |
| Push notifications | Limited, time-bounded | Full |
| ATT prompt / IDFA | Not available | Available |
| Data shared with the full app | Via a shared App Group container | n/a |
| Sign in with Apple | Yes | Yes |
| Recommending the full app | SKOverlay.AppClipConfiguration | n/a |
No ATT, no IDFA, by design
An App Clip cannot present the App Tracking Transparency prompt and cannot read the IDFA. Any measurement that assumes a device identifier fails here. What you do get is the invocation URL, which is first-party, deterministic and entirely sufficient if your links carry their own campaign parameters.
The size budget is the constraint that shapes the build. It applies to the uncompressed clip, so large frameworks, unoptimised assets and an SDK pulled in for one call are the usual reasons a clip does not fit. Attribution SDKs are worth measuring before adopting: an integration whose only job in the clip is to read a URL you already have is rarely worth the budget.
Attribution across the upgrade
The valuable event is not the invocation; it is the user who then installs the full app. The chain between them is deterministic, but only if you build it.
- The clip receives the invocation URL, including whatever campaign parameters your link carried.
- It writes what matters into a shared App Group container — the clip and the full app must declare the same group.
- The user is offered the full app, ideally through
SKOverlay.AppClipConfigurationrather than a link out. - After install, the full app reads the shared container on first launch and recovers the original URL.
- The install is attributed to the original campaign with no probabilistic matching and no device identifier involved.
| App Clip → full app | Web → App Store → full app | |
|---|---|---|
| Signal | Shared container written by the clip | Referrer, or a probabilistic match |
| Accuracy | Deterministic | Deterministic on Android, probabilistic on iOS |
| Requires an identifier | No | No, but iOS matching is weaker without one |
| Survives a device restart | Yes | Yes |
| Fails if | The App Group is misconfigured or the clip was evicted | The referrer is lost or the match window expires |
This is the strongest iOS attribution path there is
An App Clip upgrade is one of the few iOS journeys where install attribution is genuinely deterministic and requires no identifier and no fingerprint. If your use case supports a clip at all, it is worth building for measurement reasons alone.
AASA generator
Generate the apple-app-site-association file with both the appclips and applinks keys, so the same domain authorises your App Clip's invocation URLs and your full app's Universal Links. It also fetches a live domain's file so you can check the appclips entry actually reached production.
Frequently asked questions
- What is an App Clip?
- It is a small portion of an iOS app — bounded by an uncompressed size budget of 15 MB on iOS 16 and later — that a user can launch instantly from a URL, App Clip Code, NFC tag or QR code without installing the full app. It is intended for a single focused task such as ordering, renting or paying, and it can hand the user on to the full app afterwards.
- How does an App Clip receive its invocation URL?
- As an NSUserActivity of type NSUserActivityTypeBrowsingWeb, with the URL on the webpageURL property, exactly as a Universal Link arrives in a full app. For local testing you can set the _XCAppClipURL environment variable in the App Clip scheme, which makes Xcode pass a URL without any App Store Connect configuration.
- Do App Clips support IDFA and the ATT prompt?
- No. An App Clip cannot present the App Tracking Transparency prompt and cannot access the advertising identifier, so any measurement that depends on a device identifier does not work there. The invocation URL is the attribution signal instead, and because it is first-party and deterministic it is usually a better one.
- How do I attribute an install that came from an App Clip?
- Have the clip write the invocation URL, or the campaign fields from it, into an App Group container shared with the full app, then read that container on the full app's first launch. Both targets must declare the same App Group. This is deterministic and needs no device identifier and no probabilistic matching, which makes it the most reliable install attribution path on iOS.
- Does an App Clip need an entry in the AASA file?
- Yes. The apple-app-site-association file on the domain needs an appclips key whose apps array contains the App Clip's fully qualified App ID, typically the parent App ID with a .Clip suffix. That is separate from the applinks key used for Universal Links, and both can live in the same file.
Related terms
- Apple App Site Association (AASA) — The apple-app-site-association file is a JSON document hosted at a domain's /.well-known/ path that tells iOS which app is allowed to handle which URLs on that domain.
- Associated Domain — An Associated Domain is an entry in an iOS app's com.apple.developer.associated-domains entitlement that declares a domain the app is bound to for a named service, such as Universal Links or shared web credentials.
- Universal Link — A Universal Link is a standard HTTPS URL that opens an iOS app directly when that app is installed and the domain has authorised it, and loads the equivalent web page when it is not.
- Link Fallback Chain — A link fallback chain is the ordered set of destinations a single link resolves to — the app, the app store, or a web page — depending on the user's platform and whether the app is installed.