When an App Clip is worth building

This is a decision guide, not a walkthrough of the Xcode target. The APIs and the latest limits live in Apple’s App Clip documentation. Read those pages before you commit, because the size budget and some capability rules have changed before and can change again.

What an App Clip is for

An App Clip exists for a short, complete task the user may want without installing the full app first: pay for parking, order at a table, collect a ticket, start a rental, join a specific event. The system shows a card, the user opens the clip, they do the job, and later they may install the full app with their state carried across.

That is a different product shape from a demo, a teaser, or a marketing landing page. If the clip cannot complete the job — if it only advertises the app, or it stops at a sign-up wall — it is not doing what App Review or the user expects.

Good App Clips have three qualities:

• A single job you can name in a headline. “Pay for this space” is a job. “Explore our platform” is not.
• A reason the person is here, now. A code on a meter, a link in a ticket email, a tag on a table. Not a general wish that more people might try the app.
• A path into the full app that is optional, not a hostage. The clip should still succeed if they never install.

If your product is a tool people open from a home-screen icon all week, an App Clip is usually the wrong surface. Look at widgets and App Intents for glanceable or on-device entry points instead.

Invocation: links, codes, tags and the App Clip card

People do not browse an App Clip store. They arrive through an invocation:

• An App Clip Code, Apple’s own design, which can also carry a short URL.
• A QR code or an NFC tag that holds the invocation URL.
• A link in Safari, Messages or another app, with a Smart App Banner or a link that your associated domain claims.
• Maps and some system experiences, when you have configured them in App Store Connect.

All of those resolve to a URL you control, on a domain you have associated with the app, and to an App Clip experience you have configured. The card the system shows — title, image, a short subtitle — is part of the product. A vague card is a vague clip.

If you are testing QR-based invocation, generate a code that encodes the real invocation URL; the QR code generator is enough to print a trial sticker. Then tap it on a device that does not already have the full app, because that is the only honest test. NFC and App Clip Codes need physical tags or the official code tools; do not assume a simulator screenshot proves the card.

A few practical limits:

• The domain and the apple-app-site-association file have to be correct, on HTTPS, without a long redirect chain.
• Experiences can be advanced (a URL prefix per restaurant, per meter, and so on). Start with one default experience if you only have one job.
• The card is not a place to sneak a marketing essay. The clip itself should load the useful screen for that URL, not the marketing site.

The size budget and what usually blows it

Apple publishes a maximum uncompressed size for the App Clip binary in its App Clip documentation. I am not going to quote a number here as if it were fixed, because Apple has raised it before and a stale figure in an article is worse than a pointer to the current page. Look up the current limit when you budget, and treat it as a hard constraint, not a stretch goal.

What usually blows the budget, in practice:

• Large frameworks and “just in case” dependencies. A package you barely use, an animation library, a full analytics SDK.
• Images and video shipped in the clip rather than downloaded after launch, or not at all. A hero video does not belong in the binary.
• Duplicated resources that already exist in the main app but were copied instead of shared carefully.
• Debug or localisation bloat you forgot to strip. Extra languages are a product decision with a byte cost.

Budget the way you would budget a careful website. List the screens, the assets, and the third-party code, and leave headroom. The performance budget calculator and a gzip size estimator will not give you Apple’s official cap, but they help you see whether an asset set is even in the right order of magnitude before you wait for a failed archive.

Measure the actual archived clip in Xcode, not the size of a folder on disk. If you are over, cut features, do not compress your way out of a product that is still “the full app, slightly smaller”.

What an App Clip may not do

An App Clip is a restricted environment. The exact list of unavailable capabilities lives in Apple’s documentation and can change; confirm it there. In practice, you should expect limits around background work, some permission-heavy features, and anything that assumes a long-lived installed app.

Plan for these product constraints even before you read the latest table:

• The clip may be evicted, and its local data with it, if the user does not come back. Do not treat on-device storage as durable the way you would in the full app. Persist anything that matters on a server, tied to an account or a token the full app can also use.
• You should not demand a long sign-up before any value. If an account is required to complete the job (a paid rental, a stored ticket), keep it short and explain why. If it is not required, do not put a registration wall in front of the job.
• Not every API you use in the full app will be appropriate, even if it compiles. Location, camera, Bluetooth and similar permissions should be requested only when the job needs them, with the same truthful purpose strings you would use in the app.
• In-app purchases are possible through StoreKit, and Apple documents how a purchase should carry into the full app. That does not mean a clip should become a storefront. If the job is “unlock this one thing, now”, it can be justified; if the job is “browse a catalogue of subscriptions”, you probably wanted the full app. See the StoreKit 2 guide for the purchase machinery, and the App Clip docs for the current limits.

If the feature set you want is “the app, but invoked from a QR code”, you do not want an App Clip. You want a universal link into the full app, and you accept that people without the app will land on the web or the product page.

Sharing code with the main app

The App Clip is a separate target in the same Xcode project, with the same team, and a bundle identifier that is a prefix of the full app’s (the official pattern is documented by Apple). Shared work should live in a framework or a local Swift package both targets depend on, not in duplicated files.

Share:

• The model and networking for the one job the clip performs.
• The few views of that job, if they can be built without pulling in the rest of the design system.
• Account tokens and the deep-link routing that the full app will also honour.

Do not share:

• The entire design library, every analytics toolkit, and the settings screen “in case”.
• Heavy caches, onboarding, or features the clip is not allowed to offer.

The full app should be able to accept the same URL the clip accepts, and to pick up a session the clip created. That handoff is part of the work; leaving it as “we’ll do it later” is how you get two logins and a support email.

Keep the clip’s Info.plist and entitlements as small as the job. Associated domains, the App Clip capability, and only the permissions you will actually use.

A decision guide with real situations

I would build an App Clip in situations like these:

• A physical location already has to show a code or hold a tag (a table, a space, a machine, a doorway), and the job takes under a couple of minutes.
• A ticket or booking email needs a one-tap “add to device / show the gate” experience for people who have never installed the app, and the web version is clumsy at that moment.
• You already have a full app, the shared job is a small slice, and you can keep the clip inside the current size cap with room to spare.

I would not build one in situations like these:

• You do not yet have a full app, and you hoped the clip would be the app. Start with the MVP checklist and, if you need reach, a website. You can add a clip later.
• The “job” is browsing, social, or a long-lived account with no in-the-moment trigger.
• You cannot explain the invocation: there is no place to put a code, no message to put a link in, no map presence.
• The first prototype already blows the size budget, or it needs background modes and permissions that the current App Clip rules will not support.
• You are choosing between native and the web for the whole product. That is a native versus cross-platform decision, not an App Clip decision.

If you are unsure, mock the card and the first screen, and write the URL. If you cannot name the invocation, you do not have an App Clip yet.

When a well-built web page is the better clip

A website, opened from the same QR code, has advantages an App Clip does not:

• It works for people not on iOS, and for people who will not tap a system card.
• It can be searched, bookmarked and updated without an App Store review.
• It has no App Clip size cap, and no eviction of local clip data (it has its own performance and privacy problems, which are easier to iterate on).
• It is usually cheaper to maintain if you already have a decent booking or payments page.

The website is the better first surface when the job is filling in a form, reading information, or paying in a browser that already works, and when the extra smoothness of a native sheet is not the product. You can still put an App Clip behind the same URL later, with a Smart App Banner, if the numbers justify a second target.

A poor website is not an argument for an App Clip. Fix the page — mobile layout, speed, a visible button for the job — before you add a native target to hide the mess.

Review and measurement

App Review will look at the clip as a product: does it work from the invocation, does it do the job without a pointless wall, do the permission strings tell the truth, is the card accurate, and does the full app exist and correspond to the clip. Follow the current App Review Guidelines and the App Clip pages rather than a remembered checklist.

Include in your Review notes a way to invoke the clip (a URL, or a test code), and any test account the job needs. Do not expect Review to walk into a physical cafe in Manchester.

After launch, measure invocations, completions, and conversions to the full app, plus errors and size over time. If people open the card and abandon the first screen, that is usually a job or a permissions problem, not a “need more onboarding” problem. If almost nobody invokes it, you have a placement problem with the code or the link, and a better clip target will not fix that.

Key takeaways

• An App Clip is a small, invoked slice of a full app for one time-sensitive job, not a demo and not a substitute for a product.
• Invocation needs a real URL, a correct associated domain, a configured experience, and a physical or message-based reason to open it.
• Confirm Apple’s current size cap in the official docs, budget assets and dependencies with headroom, and measure the archive.
• Share a thin slice of code with the full app, persist important state on a server, and do not hide the job behind a sign-up wall.
• Skip the clip when there is no invocation, when the web already does the job, or when the first cut will not fit the limits.
• Give Review a way to invoke the clip, and measure completions, not just card impressions.

If you are deciding whether a clip is worth a target in a small app, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.