App Clips, explained for Shopify brands
An App Clip is the closest thing to app-grade checkout without an install. Here's how it works, the size ceiling almost every write-up gets wrong, and why Android now needs a completely different plan.
Written for the person who will be asked "can we do that?" and needs to answer accurately. It's the mechanics, the constraints and the failure modes — not a pitch. If you're deciding whether install-free checkout is worth pursuing at all, start with one-tap checkout is already the default.
What an App Clip actually is
Apple describes an App Clip as a lightweight version of your app that offers a slice of its functionality, available instantly without installing the full app.[5] It's not a web page in a wrapper and it's not a separate product in the App Store. It's a second build target inside your existing app project, sharing your code, shipped and reviewed alongside the parent app.
Three consequences follow immediately, and they're the ones people miss:
- You need a full app. An App Clip is distributed as part of a full app that you archive and upload to App Store Connect.[5] There's no "App Clip only" product. If you don't have an iOS app, you're building one — or you're using a platform that already has one.
- It doesn't live on the home screen. App Clips aren't managed like apps, and the system removes one from a device after a period of inactivity.[5] This is a feature, not a bug: nothing to uninstall means nothing to refuse.
- It's iOS and iPadOS 14 and later. Everyone else needs a different path — see the Android section, which is now the most important part of this article.
What happens when someone scans
The App Clip card is the screen that appears before anything runs — your image, your title, an Open button. Users don't get a choice about seeing it, so treat it as a real piece of design work rather than an afterthought. It also carries the notification note described below, which the user can switch off right there.
The size limit almost every write-up gets wrong
You'll read that App Clips can now be 100 MB. That number is real, and it almost certainly doesn't apply to you.
| Minimum deployment target | Maximum variant size | Conditions |
|---|---|---|
| iOS 17 and later | 100 MB | Only if the App Clip supports digital invocations only — your website, Spotlight — and not physical invocations like App Clip Codes, QR codes or NFC tags; is used where a reliable connection is likely; and doesn't support iOS below 17 |
| iOS 16 and later | 15 MB | — |
| Earlier than iOS 16 | 10 MB | — |
Read the conditions column twice
Two things set your ceiling, and only one of them is the invocation. A physical invocation — a code on a can, a tag in a window, a sticker on a shelf — rules out the 100 MB tier entirely, because that tier is for digital invocations only.[7] What you get instead is set by your minimum deployment target: 15 MB if you require iOS 16 or later, 10 MB if you support anything earlier.[7] So supporting iOS 14 is not free — it costs you a third of your budget. Any architecture plan that assumes 100 MB for a packaging use case is wrong before it starts.
Fifteen megabytes uncompressed is a real constraint and it shapes everything downstream:
- No heavy SDKs. A single analytics or session-replay SDK can be a meaningful fraction of the budget. Most App Clips end up with server-side event collection instead.
- No bundled catalogue. Product images, copy, prices and variants come over the network at launch. Which means your API's cold-start latency is your conversion rate — see what a tenth of a second is worth.[3]
- Shared code needs auditing. The convenient part of an App Clip — sharing code with the parent app — is also how the budget gets eaten. Anything imported transitively counts.
- Watch asset catalogues. Fonts, onboarding illustrations and localisation files are the usual culprits.
What you get for free
- Apple Pay, with card, billing address, shipping address, contact details and biometric authentication, and no typing. Worth being precise here: this is not the reason to build an App Clip — Safari gets Apple Pay too. What the App Clip adds is native rendering, no browser chrome, launch straight from the code into the product rather than into a page load, and the four capabilities below.
- Sign in with Apple, which is also one of the supported ways to carry state into the full app later.[5]
- Notifications for up to 8 hours after each launch, without a permission prompt. You opt in with the
NSAppClipRequestEphemeralUserNotificationkey; the App Clip card then shows a note about it, and the user can turn it off there.[6] For anything spanning more than a day you have to ask explicitly — and Apple warns that if the user declines, you lose the 8-hour window too.[6] - Location confirmation and Live Activities, both available to App Clips.[5]
- A route into the full app when you've earned it, with state carried over via CloudKit, Sign in with Apple, a shared container or the keychain.[5]
That 8-hour window is more interesting than it looks. It's exactly long enough for "your order is on its way" and "here's what you earned" — the two messages that turn a one-off scan into a relationship — and short enough that nobody experiences it as spam. It is also, for a first-time customer who has never given you an email address, the only channel you have.
If you're serving more than one brand
This is the part relevant to anyone running codes for several brands or SKUs from one platform — an agency, a distributor, or a service like ours.
A person can have several instances of the same App Clip on their device at once, one per business they've scanned. To route a notification to the right one, Apple requires the payload to carry a target-content-id URL that matches a registered advanced App Clip experience, and each business's URL has to be registered in App Store Connect.[6]
Practically, that means the URL structure you choose on day one is load-bearing. /brand/sku paths that map cleanly onto registered experiences will save you a migration later. Getting this wrong is not a cosmetic problem — it's notifications silently opening the wrong brand's storefront.
Android: the plan changed in December 2025
If you read anything from before 2026 about "App Clips and their Android equivalent", it's out of date. Google Play Instant — Android's install-free app runtime — has been removed. Google's own documentation states that from December 2025, Instant Apps cannot be published through Play, all Play services Instant APIs stopped working, and users are no longer served Instant Apps by any mechanism.[8] The recommended alternative is to send people to the regular app via deep links.[8]
What this means in practice
On Android there is now no install-free native runtime at all. The install-free path is the mobile web. So a printed code has to resolve to a URL that works brilliantly as a web page, and additionally triggers the App Clip on iOS. If your plan was "App Clip on iOS, Instant App on Android", you no longer have an Android plan — you have a web performance project, and it's the more important half by user count.
This is a genuinely good outcome for anyone who was already building web-first. It collapses a two-runtime problem into one-and-a-bit: a fast, wallet-enabled mobile store that everyone gets, plus a native fast path for iOS users who scan a code. It's an uncomfortable outcome for anyone whose product strategy was "native everywhere".
Choosing between the three options
| Option | Install cost to customer | Reach | Choose this when |
|---|---|---|---|
| Fast mobile store + wallet button | None | Everyone | Always. This is the floor, not an alternative — it's what Android users and every non-scanning visitor will get regardless. |
| App Clip | None | iOS/iPadOS 16+ at a 15 MB budget (14+ only if you accept 10 MB) | You have physical surfaces, iOS skews high in your customer base, and the marginal experience gain over good mobile web justifies maintaining an app target. |
| Full native app | High — an install, a wait, a decision | People who already love you | You have genuine repeat-purchase behaviour to serve and enough loyal customers that an install is a reasonable ask. Not an acquisition tool. |
Our bias, stated plainly: we build the first two, so read the table with that in mind. The claim we'd defend anywhere is the first row — if your mobile store is slow, no runtime choice above it will save you.
What it takes to ship one
Have (or get) a parent app
An App Clip target lives inside a full app project and is uploaded with it.[5] This is the step that ends most in-house App Clip projects, and the reason platforms exist.
Associate the domain
Serve an
apple-app-site-associationfile so the system can verify your App Clip for invocations from your website and older iOS versions.[5] It has to be served correctly at the right path with the right content type — and it must not be shadowed by a catch-all route, which is an easy mistake on a store that maps arbitrary paths to products.Design the invocation URL structure
Before you print anything. It determines your App Store Connect experiences, your notification routing, and how painful multi-brand gets.[6]
Register experiences in App Store Connect
Default and advanced experiences, one per business or per campaign as your URL structure demands.
Generate the codes
App Clip Codes come in NFC-integrated and scan-only forms.[5] Encoding the URL efficiently matters — shorter URLs give a more reliable scan at small print sizes, which is precisely where packaging lives.
Budget the bytes, then test on a real device
Against the 15 MB ceiling[7], from a printed code, in a shop, on cellular. Simulator testing will not tell you what a code looks like under supermarket lighting on a curved can.
When not to do this
An honest list, because getting this wrong is expensive in print costs:
- Your mobile site is slow. Fix that first. It's cheaper, it helps every visitor rather than a subset, and it's the Android path anyway. Start with why mobile converts at roughly half the rate of desktop.
- You have no physical surfaces. App Clips earn their keep at the boundary between physical and digital, and what a QR code on your packaging is actually worth is the arithmetic that decides it. Pure DTC with no packaging presence gets most of the benefit from a wallet button.
- Your product needs consideration. A £900 mattress is not an impulse scan. This is a mechanism for products where the decision is already made or takes seconds.
- Nobody owns it internally. An App Clip is an app-store artefact with review cycles, entitlements, certificates and expiry dates. If there's no one to own that, use a platform that does, or stay on the web.
Sources
- Deloitte with Google, Milliseconds Make Millions — 30m sessions, 37 brands. Primary ↩
- Apple, App Clips framework documentation — definition, removal after inactivity, distribution with the full app, App Clip Codes, data sharing, Live Activities. Primary ↩
- Apple, Enabling notifications in App Clips — the 8-hour ephemeral window,
NSAppClipRequestEphemeralUserNotification, andtarget-content-idrouting for multi-business App Clips. Primary ↩ - Apple, Maximum build file sizes — App Clip size tiers and the digital-invocations-only condition on the largest one. Primary ↩
- Google, Google Play Instant — deprecation notice: from December 2025 Instant Apps cannot be published and Instant APIs no longer work. Primary ↩