App Clips

App Clips

Lightweight, instantly available versions of your iOS app for in-the-moment experiences or demos. Targets iOS 26+ / Swift 6.3 unless noted.

Contents

• App Clip Target Setup
• Invocation and Experience Routing
• Size and Capability Decisions
• Data, Notifications, and Location
• Common Mistakes
• Review Checklist
• References

App Clip Target Setup

An App Clip is a separate target in the same Xcode project as your full app:

1. File → New → Target → App Clip — Xcode creates the App Clip target, adds the Embed App Clip build phase to the full app target, and wires the association entitlements. 2. The App Clip bundle ID must be prefixed by the full app's bundle ID: com.example.MyApp.Clip. 3. Verify raw entitlement keys when diagnosing archive, signing, or App Store Connect failures:

• App Clip target: com.apple.developer.on-demand-install-capable
• App Clip target parent app link: com.apple.developer.parent-application-identifiers
• Full app target associated App Clip link: com.apple.developer.associated-appclip-app-identifiers

Use Swift packages or shared source files for code needed by both targets. Add App Clip-specific compile branches with the APPCLIP active compilation condition, and avoid linking full-app-only frameworks into the App Clip target.

Invocation and Experience Routing

Read `references/routing-and-experiences.md` when implementing invocation URL routing, App Store Connect experiences, Local Experiences, Safari Smart App Banners, QR/NFC/App Clip Codes, AASA, or associated domains.

App Clips receive NSUserActivityTypeBrowsingWeb activities. Keep the invocation router shared with the full app because, after installation, the full app replaces the App Clip and receives future invocations.

• SwiftUI: use .onContinueUserActivity(NSUserActivityTypeBrowsingWeb).
• UIKit cold launch: inspect connectionOptions.userActivities in scene(_:willConnectTo:options:).
• UIKit continuation: handle the actual NSUserActivity in scene(_:continue:).
• scene(_:willContinueUserActivityWithType:) is only advance notice and does not provide the URL.

Configure the required default App Clip experience in App Store Connect. Use advanced experiences for Maps integration, location association, production App Clip Codes, per-location cards, and precise physical-place routing; demo App Clip Codes can use the short demo App Clip link.

For custom URLs, add appclips:example.com to Associated Domains on both the full app and App Clip targets, and host an AASA file with the App Clip app identifier. For Safari banners, use app-id, app-clip-bundle-id, and optional app-clip-display=card; do not rely on app-argument for App Clip launches.

Size and Capability Decisions

Read `references/size-capabilities-and-promotion.md` before feasibility reviews or capability audits, and when checking size budgets, measurement, Background Assets, SKOverlay, Live Activities App Clip extension constraints, CloudKit limits, or unsupported capabilities.

Always measure App Clip size with the App Thinning Size Report. In feasibility reviews, explicitly choose the size limit from deployment target, invocation support, and connectivity: the larger iOS 17+ limit applies to digital-only App Clips where reliable internet is likely; physical invocation or iOS 16 support uses a smaller budget; demo links can use the current 100 MB limit while supporting NFC/QR test invocations, and demo App Clip Codes require the short demo link. Apple has changed App Clip size policy over time, so re-check current App Store Connect and App Clip documentation before release-blocking size decisions.

Use Background Assets only for content that can arrive after launch without blocking the in-the-moment task, and do not mark App Clip background asset downloads as essential. Large bundled media, ML models, catalogs, or downloads that must finish before useful work are poor App Clip fits; state that required pre-task downloads are not acceptable for in-the-moment App Clips, and check download size plus whether any required download blocks useful work. Move those flows to streaming/server-backed content, post-task assets, or the full app. Show SKOverlay.AppClipConfiguration or SwiftUI appStoreOverlay only after task completion, never as a gate.

App Clips can use CloudKit public database reads on iOS 16+ with CloudKit-Anonymous, but cannot write the public database or use iCloud Documents, key-value storage, private containers, or shared containers. App Clips can offer Live Activities through an App Clip-only widget extension starting in iOS 16. That extension can include only Live Activities and needs the App Clip Extension capability; always include the raw entitlement key com.apple.developer.on-demand-install-capable when reviewing this boundary.

In feasibility reviews, explicitly name unsupported App Clip runtime features instead of summarizing them generically. Always list SKAdNetwork, App Tracking Transparency, and custom URL schemes when discussing excluded runtime features, alongside App Intents, Background Tasks, background URL sessions, in-app purchases, durable persistent local state, and background/persistent assumptions. Route detailed ActivityKit/WidgetKit Live Activity work, StoreKit purchase/full-app monetization, BackgroundTasks processing, CloudKit schema or sync beyond public reads, durable credentials, and long-term state to sibling or full-app domains without implementation detail. For product/PM feasibility reviews, stay at the App Clip boundary level: capability fit, size basis, invocation constraints, and handoff destinations. Describe location confirmation, install promotion, App Group/keychain handoff, and Live Activities conceptually. Do not add Swift package decomposition, API symbols such as APActivationPayload, CLCircularRegion, or SKOverlay.AppClipConfiguration, App Group/keychain implementation recipes, or other API-level implementation guidance unless the user asks for implementation.

Data, Notifications, and Location

Read `references/data-handoff-notifications-location.md` when implementing App Group/full-app migration, keychain or Sign in with Apple handoff, ephemeral notifications, notification relaunch routing, or physical location confirmation.

Use App Groups/shared containers for non-secret handoff data only. Any target provisioned with the App Group entitlement can read and write the shared container/defaults suite, so it is not a trust boundary. Do not put passwords, refresh tokens, payment credentials, or other secrets there.

Starting in iOS 15.4, the full app can access keychain items created by its corresponding App Clip only when the App Clip and full app have the correct association entitlements, including the full app's com.apple.developer.associated-appclip-app-identifiers. The App Clip cannot read keychain items created by the full app.

For Sign in with Apple handoff, store the ASAuthorizationAppleIDCredential.user identifier and have the full app verify ASAuthorizationAppleIDProvider.getCredentialState(forUserID:) == .authorized.

For ephemeral notifications, set NSAppClipRequestEphemeralUserNotification under the App Clip target's NSAppClip Info.plist dictionary. Authorization can last up to 8 hours after each launch, but users can disable it on the App Clip card, so check notification settings for .ephemeral before scheduling. Notification taps relaunch without the original invocation URL, so route multi-experience notifications with APNs target-content-id for remote notifications or UNNotificationContent.targetContentIdentifier for local notifications. Use a URL matching the relevant App Store Connect advanced App Clip experience, not an arbitrary opaque ID.

For physical-location confirmation, use NSUserActivity.appClipActivationPayload / APActivationPayload.confirmAcquired(in:) with a CLCircularRegion radius up to 500 meters, and set NSAppClipRequestLocationConfirmation under the App Clip target's NSAppClip Info.plist dictionary, not the full app's. This confirms eligible physical invocations without granting continuous location access.

Common Mistakes

Exceeding the applicable App Clip size limit

Choose the limit based on deployment target and invocation support. A physically invoked App Clip that supports iOS 16 has a much smaller budget than an iOS 17+ digital-only App Clip. Measure with the App Thinning Size Report after meaningful target changes.

Mixing up App Clip entitlement names

App Clip target:
com.apple.developer.on-demand-install-capable
com.apple.developer.parent-application-identifiers

Full app target:
com.apple.developer.associated-appclip-app-identifiers

Display names in Xcode differ from raw entitlement keys; use raw keys when debugging signing output or archived entitlements.

Treating UIKit continuation notification as URL handling

scene(_:willContinueUserActivityWithType:) does not include the NSUserActivity. Handle the URL in scene(_:willConnectTo:options:) for cold launch and scene(_:continue:) for activity continuation.

Not testing invocation URLs locally

A direct Xcode launch can skip the invocation path and hide routing bugs. Use the _XCAppClipURL scheme environment variable or register a Local Experience in Settings → Developer → Local Experiences.

Not handling the full app replacing the App Clip

Share invocation routing with the full app. After install, all future invocations go to the full app.

Storing secrets in App Group storage

Use App Groups for non-secret handoff state only. Use keychain or server-side verification for credentials.

Designing a marketing-only or web-view-heavy App Clip

App Clips should let people complete a focused task or full demo without installing the app. Avoid marketing-only clips, ad-heavy flows, splash screens, launch-blocking downloads, repeated install prompts, and web-view-heavy experiences that would work better as a website.

Missing associated domains configuration

Add appclips:example.com to Associated Domains on both the full app and App Clip targets, and host /.well-known/apple-app-site-association with the App Clip app identifier for custom URL invocations and advanced experiences.

Review Checklist

• [ ] App Clip target bundle ID is prefixed by the full app's bundle ID.
• [ ] App Clip target has com.apple.developer.on-demand-install-capable.
• [ ] App Clip target has com.apple.developer.parent-application-identifiers.
• [ ] Full app target has com.apple.developer.associated-appclip-app-identifiers.
• [ ] Shared code uses Swift packages or compilation conditions (APPCLIP).
• [ ] SwiftUI uses .onContinueUserActivity(NSUserActivityTypeBrowsingWeb) for invocation routing.
• [ ] UIKit cold launch checks connectionOptions.userActivities and continuation handles scene(_:continue:).
• [ ] Full app handles every invocation URL the App Clip supports.
• [ ] App Thinning Size Report confirms the binary is within the limit for deployment target and invocation support; size reviews name the 10 MB, 15 MB, and current 100 MB tiers when size is at issue.
• [ ] Associated Domains entitlement includes appclips:yourdomain.com on both full app and App Clip targets when using custom URLs.
• [ ] AASA file is hosted at /.well-known/apple-app-site-association when using custom URLs.
• [ ] Default App Clip experience is configured in App Store Connect.
• [ ] Production App Clip Codes, Maps, or per-location cards use advanced experiences; demo App Clip Codes use the short demo link.
• [ ] Live Activities, when mentioned, are limited to an App Clip-only widget extension with only Live Activities and the raw com.apple.developer.on-demand-install-capable entitlement.
• [ ] Shared App Group storage contains only non-secret data the full app needs, never credentials or payment secrets.
• [ ] Keychain handoff states the one-way rule: the full app can read App Clip-created items on iOS 15.4+ with correct association entitlements, but the App Clip cannot read full-app keychain items.
• [ ] Sign in with Apple migration verifies credential state in the full app.
• [ ] SKOverlay / appStoreOverlay appears after task completion, never as a gate.
• [ ] NSAppClipRequestLocationConfirmation is set only in the App Clip target if using location confirmation.
• [ ] Ephemeral notification code checks for .ephemeral authorization before scheduling because the card permission can be disabled.
• [ ] Ephemeral notification routing handles relaunch without an invocation URL.
• [ ] HIG review rejects marketing-only, ad-heavy, web-view-heavy, install-gated, or launch-blocking App Clip designs.
• [ ] Unsupported runtime features are named explicitly, including durable persistent local state and background/persistent assumptions, not just unavailable frameworks.
• [ ] No reliance on background processing, restricted frameworks, custom URL schemes, in-app purchases, or persistent local storage.
• [ ] Sibling handoff is boundary-only, with no ActivityKit, StoreKit, BackgroundTasks, CloudKit, Swift package, App Group/keychain recipe, location-confirmation API symbol, SKOverlay, or framework-snippet implementation detail in App Clip feasibility answers.
• [ ] Tested with Local Experiences and _XCAppClipURL.

References

• Routing and experiences
• Data handoff, notifications, and location
• Size, capabilities, and promotion
• App Clips framework
• Creating an App Clip with Xcode
• Configuring App Clip experiences
• Responding to invocations
• Choosing the right functionality
• Confirming a person's physical location
• Sharing data between App Clip and full app
• Enabling notifications in App Clips
• Supporting invocations from your website and the Messages app
• Offering Live Activities with your App Clip
• Recommending your app to App Clip users
• APActivationPayload
• SKOverlay.AppClipConfiguration
• NSUserActivityTypeBrowsingWeb
• Creating App Clip Codes
• Distributing your App Clip
• App Clips HIG

App Clip Data Handoff, Notifications, and Location

Use this when implementing App Group/full-app migration, keychain or Sign in with Apple handoff, ephemeral notifications, notification relaunch routing, or physical location confirmation.

Contents

• Data Migration to Full App
• Keychain Sharing
• Sign in with Apple
• Ephemeral Notifications
• Location Confirmation
• Lifecycle and Ephemeral State

Data Migration to Full App

When a user installs the full app, it replaces the App Clip. Use a shared App Group container for non-secret data the full app needs:

// In both targets: add App Groups capability with the same group ID

// App Clip — write non-secret data
func savePendingOrder(_ order: PendingOrder) throws {
    guard let containerURL = FileManager.default.containerURL(
        forSecurityApplicationGroupIdentifier: "group.com.example.myapp.shared"
    ) else { return }

    let data = try JSONEncoder().encode(order)
    let fileURL = containerURL.appendingPathComponent("pending-order.json")
    try data.write(to: fileURL)
}

// Full app — read migrated data
func loadPendingOrder() throws -> PendingOrder? {
    guard let containerURL = FileManager.default.containerURL(
        forSecurityApplicationGroupIdentifier: "group.com.example.myapp.shared"
    ) else { return nil }

    let fileURL = containerURL.appendingPathComponent("pending-order.json")
    guard FileManager.default.fileExists(atPath: fileURL.path) else { return nil }
    let data = try Data(contentsOf: fileURL)
    return try JSONDecoder().decode(PendingOrder.self, from: data)
}

Shared UserDefaults

Use shared defaults for small, non-secret state such as identifiers, timestamps, feature choices, or pending-cart metadata:

let shared = UserDefaults(suiteName: "group.com.example.myapp.shared")
shared?.set(orderID, forKey: "pendingOrderID")

Any app or extension target provisioned with the same App Group entitlement can read and write the shared container and shared defaults suite. Treat App Group storage as a convenience handoff channel, not a trust boundary. Do not put passwords, refresh tokens, payment credentials, or other secrets in shared containers or shared defaults.

Keychain Sharing

Starting in iOS 15.4, the full app can access keychain items created by its corresponding App Clip when the App Clip and full app have the correct association entitlements. This is one-way: the App Clip cannot read keychain items created by the full app. Use labels, service names, or account naming to distinguish App Clip-created items before migration.

Sign in with Apple

Store the ASAuthorizationAppleIDCredential.user identifier in the shared container so the full app can verify the account without re-prompting unnecessarily:

let provider = ASAuthorizationAppleIDProvider()
provider.getCredentialState(forUserID: userID) { state, error in
    if state == .authorized {
        // Continue full-app account migration.
    }
}

Ephemeral Notifications

App Clips can request ephemeral notification authorization by setting NSAppClipRequestEphemeralUserNotification in the App Clip target's NSAppClip Info.plist dictionary. The authorization can last up to 8 hours after each launch, but users can disable it from the App Clip card. Before scheduling, check UNUserNotificationCenter settings and require authorizationStatus == .ephemeral.

A notification tap relaunches the App Clip without the original invocation URL. For multi-experience App Clips, include a target content identifier so the App Clip can route after notification relaunch. Use a URL matching the relevant App Store Connect advanced App Clip experience, not an arbitrary opaque ID:

• Remote notifications: APNs target-content-id
• Local notifications: UNNotificationContent.targetContentIdentifier

Location Confirmation

Use APActivationPayload to verify a user's physical location without requesting full location access. The confirmation region can have a radius up to 500 meters:

import AppClip
import CoreLocation

func verifyLocation(from activity: NSUserActivity) {
    guard let payload = activity.appClipActivationPayload else { return }

    let center = CLLocationCoordinate2D(latitude: 37.334722, longitude: -122.008889)
    // Apple allows a confirmation region radius up to 500 meters.
    let region = CLCircularRegion(center: center, radius: 100, identifier: "store-42")

    payload.confirmAcquired(in: region) { inRegion, error in
        if let error = error as? APActivationPayloadError {
            switch error.code {
            case .doesNotMatch:
                break
            case .disallowed:
                break
            @unknown default:
                break
            }
            return
        }

        if inRegion {
            routeToInStoreExperience()
        }
    }
}

Enable location confirmation in the App Clip target's Info.plist, not the full app's:

<key>NSAppClip</key>
<dict>
    <key>NSAppClipRequestLocationConfirmation</key>
    <true/>
</dict>

This is lightweight: the system confirms whether the invocation is within your registered physical region without granting continuous location access. The App Clip card discloses that the clip can verify location. Available iOS 14.0+.

Lifecycle and Ephemeral State

• No Home Screen icon — App Clips appear in the App Library and recent apps.
• Automatic removal — the system may remove unused App Clips and their data after a limited, system-determined period.
• No persistent state guarantee — treat App Clip local storage as ephemeral; migrate important non-secret data to the shared container or a server.
• Relaunching — returning from the App Library uses the last invocation URL; returning from the App Switcher launches without an invocation URL, so restore saved state.
• Location access — use when-in-use authorization only; App Clip location authorization is short-lived and resets.

App Clip Routing and Experiences

Use this when implementing invocation URL routing, App Store Connect experiences, Local Experiences, Safari Smart App Banners, QR/NFC/App Clip Codes, AASA, or associated domains.

Contents

• Invocation URL Handling
• App Clip Experience Configuration
• Invocation Methods
• Safari Smart App Banner
• Local Testing

Invocation URL Handling

App Clips receive an NSUserActivity of type NSUserActivityTypeBrowsingWeb. Route from the invocation URL and keep the same router available to the full app.

SwiftUI

@main
struct DonutShopClip: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { activity in
                    handleInvocation(activity)
                }
        }
    }

    private func handleInvocation(_ activity: NSUserActivity) {
        guard let url = activity.webpageURL,
              let components = URLComponents(url: url, resolvingAgainstBaseURL: true)
        else { return }

        let locationID = components.queryItems?
            .first(where: { $0.name == "location" })?.value

        routeToLocation(id: locationID)
    }
}

UIKit scenes

For UIKit scene-based apps, distinguish notification from handling:

• Cold launch: inspect connectionOptions.userActivities in scene(_:willConnectTo:options:).
• Continued activity: handle the actual NSUserActivity in scene(_:continue:).
• Relaunch warning: scene(_:willContinueUserActivityWithType:) can tell you a continuation is coming, but it does not provide the activity or URL.

Key rule: The full app must handle every invocation URL the App Clip supports. After a user installs the full app, it replaces the App Clip and receives future invocations.

App Clip Experience Configuration

Configure experiences in App Store Connect after uploading a build containing the App Clip.

Default App Clip experience

• Required for every App Clip.
• Provide: header image, subtitle, and call-to-action verb.
• App Store Connect generates a default App Clip link with an appclip.apple.com URL.
• Supports web and shared-link invocation; QR and NFC can encode links, but count as physical triggers for size-policy decisions.

Demo App Clip link

• Auto-generated by App Store Connect for demo versions of your app.
• Supports NFC tags and QR codes for testing physical invocations.
• App Clip Codes require the short version of the demo App Clip link.
• Does not replace Maps, Smart App Banners, or website App Clip cards.
• Can use the larger current App Clip binary limit.
• Cannot contain URL parameters.

Advanced App Clip experiences

• Required for: Maps integration, location association, per-location card imagery, and precise physical-place routing.
• Normal production path for App Clip Codes; demo App Clip Codes require the short demo link.
• Each experience has its own invocation URL, header image, and metadata.
• URL prefix matching lets one registered URL cover many sub-paths.
• Use the App Store Connect API to manage large numbers of experiences programmatically.

Associated domains

For custom URLs, add entries to the Associated Domains entitlement on both the full app and App Clip targets, and host an AASA file:

appclips:example.com

Invocation Methods

Safari Smart App Banner

Add this meta tag to your website to show the App Clip banner:

<meta name="apple-itunes-app"
      content="app-id=YOUR_APP_ID, app-clip-bundle-id=com.example.MyApp.Clip,
               app-clip-display=card">

Use app-clip-display=card when the webpage should display the App Clip card in Safari or SFSafariViewController on iOS 15+. Do not rely on app-argument for App Clips; Apple documents app-argument for full-app Smart App Banners, not App Clip launches.

Local Testing

Test the invocation path, not just direct Xcode launch:

// Use the _XCAppClipURL environment variable in the scheme,
// or register a Local Experience in Settings → Developer → Local Experiences.

A direct Xcode launch can skip the invocation path and hide routing bugs.

App Clip Size, Capabilities, and Promotion

Use this before App Clip feasibility reviews or capability audits, and when checking size budgets, measurement, Background Assets, SKOverlay, Live Activities App Clip extension constraints, CloudKit limits, or unsupported capabilities.

Contents

• Feasibility Review Template
• Size Limits
• Background Assets
• SKOverlay for Full App Promotion
• Capabilities and Limitations
• Additional Restrictions

Feasibility Review Template

For capability reviews, explicitly cover:

• Size basis: deployment target, physical versus digital invocation, reliable-internet expectation, App Thinning Size Report, and demo-link/App Clip Code constraints.
• Download fit: large bundled media, ML models, catalogs, or required pre-task downloads should move to streaming/server-backed content, post-task assets, or the full app.
• UX fit: reject marketing-only, ad-heavy, web-view-heavy, install-gated, or launch-blocking App Clip designs.
• CloudKit boundary: App Clips can read the public database on iOS 16+ with CloudKit-Anonymous; do not plan public writes, iCloud Documents, key-value storage, private/shared containers, full CloudKit sync, or durable offline state in the App Clip.
• Live Activities boundary: App Clip-only widget extension, Live Activities only, App Clip Extension capability, and exact raw entitlement key com.apple.developer.on-demand-install-capable; hand implementation details to ActivityKit/WidgetKit.
• Unsupported runtime features: name App Intents, Background Tasks, background URL sessions, custom URL schemes, in-app purchases, durable persistent local state, SKAdNetwork, and App Tracking Transparency when relevant.
• Sibling handoff: keep this skill at feasibility and App Clip boundary level; route StoreKit purchases, BackgroundTasks, CloudKit schema/sync, detailed ActivityKit/WidgetKit work, durable credentials, and long-term state to sibling or full-app domains.
• Depth control: for product/PM feasibility reviews, stop at capability fit, size basis, invocation constraints, and handoff destinations. Describe location confirmation, install promotion, App Group/keychain handoff, and Live Activities conceptually. Do not add Swift package decomposition, API symbols such as APActivationPayload, CLCircularRegion, or SKOverlay.AppClipConfiguration, App Group/keychain implementation recipes, or other API-level implementation guidance unless the user asks for implementation.

Size Limits

App Clip binaries must stay within strict uncompressed size limits, measured with the App Thinning Size Report:

The larger iOS 17+ limit is for digital invocations where a reliable internet connection is likely, when the App Clip does not support physical invocations and does not support iOS 16 or earlier. Physical invocation or iOS 16 support uses a smaller budget. App Store Connect demo links can use the larger limit while supporting NFC tags and QR codes for testing; demo App Clip Codes require the short demo link. Apple has changed App Clip size policy over time, so re-check the current App Store Connect and App Clip documentation before making release-blocking decisions.

Measure size: Archive the app → Distribute → Export as Ad Hoc/Development with App Thinning → check App Thinning Size Report.txt.

For feasibility reviews, name the size basis explicitly: deployment target, physical versus digital invocation, reliable-internet expectation, and whether demo links or App Clip Codes are in scope.

Background Assets

Use Background Assets only for content that can arrive after launch without blocking the in-the-moment task. App Clips cannot set a background asset download's priority to essential with isEssential. They are a poor fit for large bundled media, ML models, catalogs, or downloads that must finish before useful work. Move those flows to streaming/server-backed content, post-task assets, or the full app.

SKOverlay for Full App Promotion

Display an overlay recommending the full app from within the App Clip.

SwiftUI

struct OrderCompleteView: View {
    @State private var showOverlay = false

    var body: some View {
        VStack {
            Text("Order placed!")
            Button("Get the full app") { showOverlay = true }
        }
        .appStoreOverlay(isPresented: $showOverlay) {
            SKOverlay.AppClipConfiguration(position: .bottom)
        }
    }
}

UIKit

func displayOverlay() {
    guard let scene = view.window?.windowScene else { return }

    let config = SKOverlay.AppClipConfiguration(position: .bottom)
    let overlay = SKOverlay(configuration: config)
    overlay.delegate = self
    overlay.present(in: scene)
}

SKOverlay.AppClipConfiguration resolves to the App Clip's corresponding full app. Available iOS 14.0+.

Never block the user's task to force installation — show the overlay after task completion.

Capabilities and Limitations

Available to App Clips

SwiftUI, UIKit, Core Location (when-in-use), Sign in with Apple, Apple Pay, CloudKit public database reads only with CloudKit-Anonymous (iOS 16+), Background Assets, StoreKit SKOverlay, Keychain, App Groups, ephemeral notifications, and Live Activities through an App Clip-only widget extension.

Live Activities

Starting in iOS 16, an App Clip can offer a Live Activity through a widget extension that belongs only to the App Clip. That extension can include only Live Activities, not ordinary widgets, and it needs the App Clip Extension capability. When reviewing this boundary, always name the exact raw entitlement key: com.apple.developer.on-demand-install-capable. Keep detailed ActivityKit and WidgetKit implementation guidance in those sibling skills.

Not available / no runtime functionality

In feasibility reviews, explicitly name restricted or unsupported App Clip runtime features instead of summarizing them generically: App Intents, Background Tasks, background URL sessions, custom URL schemes, in-app purchases, durable persistent local state, SKAdNetwork, App Tracking Transparency, CallKit, Contacts, CoreMotion, EventKit, HealthKit, HomeKit, MediaPlayer, Messages, NearbyInteraction, PhotoKit, SensorKit, and Speech.

Additional Restrictions

• No background URL sessions.
• No background Bluetooth.
• No multiple scenes on iPad.
• No on-demand resources.
• No custom URL schemes.
• No in-app purchases; reserve purchase flows for the full app and StoreKit sibling guidance.
• No durable local-state guarantee; migrate important non-secret state to a server or full-app handoff.
• No CloudKit public writes, iCloud Documents, iCloud key-value storage, private containers, or shared containers.
• No App Clip design that requires install, marketing exposure, web-view navigation, or blocking downloads before the user gets value.
• Hand off detailed ActivityKit/WidgetKit Live Activity implementation, StoreKit purchase/full-app monetization, BackgroundTasks processing, CloudKit schema or sync beyond public reads, durable credentials, and long-term state to sibling or full-app domains without adding implementation detail here.
• In feasibility answers, avoid implementation-level Swift package routing, App Group/keychain recipes, location-confirmation API symbols, SKOverlay API calls, or framework snippets unless the user explicitly asks for implementation.
• UIDevice.name and identifierForVendor return empty strings.