The little card that already knows what it wants
You tap an NFC tag at a coffee counter. A small card slides up from the bottom of your screen, and before you've agreed to anything, before you've even read the name of the business, it's already asking for your location. No app installed. No App Store visit. Just a lightweight sliver of software that materialized in seconds and immediately wants to know where you are.
That moment feels either impressively smooth or faintly alarming. Either way, it raises a real question: who decided this particular App Clip would ask for location, and why didn't it also ask for your camera? The answer lives inside a surprisingly deliberate permission architecture that Apple built into the App Clip specification itself.
The whitelist carved into the spec
App Clips can only request a specific, hardcoded subset of permissions. Full stop.
This isn't a developer choosing to be polite. It's a constraint baked into the platform. The permitted categories are: location (while the app is in use), the camera, the microphone, and Bluetooth. Notifications get a special lightweight version. That's essentially the list. An App Clip cannot ask for your contacts, your photos library, your health data, your Face ID enrollment, or your full notification history. Those requests are physically blocked at the API level. If a developer tries to call the contacts framework from an App Clip target, the system returns nothing, silently, like a door that doesn't even bother to say it's locked.
This matters because the permission dialog you see isn't a choice the developer made at runtime. It's something they declared in advance, during the build, and Apple's review process checks that declaration against what the clip actually calls.
How the clip's purpose shapes the ask
Here's the part most explanations skip entirely.
An App Clip isn't just a small app. It's a distinct Xcode target with its own entitlements file, separate from the full app. That file lists the capabilities the developer is requesting for the clip specifically. When the clip launches, iOS reads those entitlements and builds a permission request profile before a single line of the clip's own code runs.
So when you tap that coffee shop NFC tag, the sequence goes roughly like this: the system fetches the App Clip bundle, validates the entitlements, and if location is declared, it prepares the Core Location permission prompt. The clip's code then calls `requestWhenInUseAuthorization()` and the pre-validated prompt appears. The whole thing feels instantaneous because the validation work happened during the clip's download, not after launch. The system isn't waiting to see what the clip does. It already knows.
The scenario that makes it concrete
Two parking apps. Different teams. Both use App Clips triggered by QR codes on parking meters.
Team A's clip needs your location to pre-fill the parking zone and your camera to scan a meter serial number. They declare both entitlements. You scan the QR code, you get two prompts: location while in use, then camera access. Slightly annoying, but each request has an obvious job.
Team B's developer started with their full app's entitlements file and forgot to trim it for the clip target. They left in a microphone entitlement even though the clip has no voice feature. Apple's review process will flag this during submission, but if it somehow slipped through, the microphone prompt would appear anyway, because the entitlement is declared. The user sees a microphone request with no visible reason. Trust evaporates, fast.
That's the practical edge of the system: the permission request is a direct mirror of the entitlements file, not a mirror of the clip's actual runtime behavior. Sloppiness in that file shows up immediately, on the user's screen, with your company's name above it.
Location gets special treatment
Of all the permissions an App Clip can request, location has the most deliberate constraints. App Clips can only ever request "when in use" authorization. They cannot request "always on" background location, even if a developer declares the always-on entitlement. The system downgrades it to when-in-use for clip targets automatically.
The reasoning is straightforward: App Clips are designed for transactional, present-moment interactions. You're at a restaurant, you scan, you order, you leave. Giving a clip background location access would be like handing someone the keys to your car because they needed to borrow a pen.
There's also a time cap. App Clips stop functioning after a period of inactivity (roughly eight hours without engagement, though exact behavior can vary by iOS version and system conditions). Granting persistent location access to something with a built-in expiry would be architecturally incoherent. The permission model and the lifecycle model are designed together, and that coordination is not an accident.
What people consistently misread
The most common misunderstanding is that App Clip permission requests are somehow less binding than full-app permission requests.
They aren't. When you grant location access to an App Clip, that grant is real. And here's the part worth knowing before it surprises you: if you later install the full app from the same developer, iOS transfers that permission grant automatically. You don't get prompted again.
This transfer is deliberate and documented. But it catches people off guard. You said yes to a tiny card at a parking meter. Three days later the full app is on your phone and it already has location access. Nothing shady happened. The system worked as designed. But if you weren't expecting it, it feels like something slipped past you.
So be as deliberate about App Clip permission prompts as you would with a full app install. They're not previews of future requests. They're the real thing.
The camera prompt that never comes
Not every permission a clip could technically request will always appear. iOS applies what it calls "purpose string" validation: every permission request must include a human-readable explanation of why that permission is needed, written by the developer and reviewed by Apple. Missing from the clip's Info.plist? The system kills the permission request before it reaches you.
A clip built to scan QR codes for a restaurant menu might declare camera access, write a clear purpose string like "used to scan your table's menu code," and the prompt appears naturally. A clip that declares camera access but provides a vague or missing purpose string gets blocked at review. This is one place where Apple's review process does genuinely useful work before the user ever sees anything, and I'd argue it's more effective than most people give it credit for.
If you've ever been through a clip experience that asked for exactly one permission and nothing more, that precision wasn't accidental. It was the entitlements whitelist, the developer's declared capabilities, and the purpose string review all working in sequence.
The architecture is the argument
Most mobile permission systems are reactive: the app launches, runs code, requests access when it needs something. The App Clip model is declarative. You state what you need before the user ever interacts with the clip, and the system holds you to that declaration.
That's a more honest architecture, and it's worth saying plainly. It forces the developer to think about permissions as part of the clip's design, not as runtime conveniences bolted on later. It gives Apple a clear review surface. It gives the user a permission prompt that corresponds to something the developer committed to in writing.
The coffee shop clip that asked for your location the second it appeared wasn't overstepping. It was doing exactly what its creator declared it would do, inside a framework designed to make that declaration visible and permanent. Whether you find that reassuring or unsettling probably says something about how much you trust the review process sitting between the developer's entitlements file and your screen. That trust, it turns out, is load-bearing.