Implementing App Clips with Rork Max — delivering the core of your app the moment someone scans a code

Receiving the launch URL through NSUserActivity

An App Clip launches from a URL. You bind a URL like https://example.com/w?id=1042 to a QR code or App Clip Code, receive it on launch, and go straight to the target screen.

In SwiftUI, you receive NSUserActivityTypeBrowsingWeb in onContinueUserActivity and read its webpageURL.

import SwiftUI
 
@main
struct WallpaperClipApp: App {
    @State private var wallpaperID: String?
 
    var body: some Scene {
        WindowGroup {
            ClipRootView(wallpaperID: wallpaperID)
                .onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { activity in
                    guard let url = activity.webpageURL else { return }
                    wallpaperID = parseWallpaperID(from: url)
                }
        }
    }
 
    private func parseWallpaperID(from url: URL) -> String? {
        let components = URLComponents(url: url, resolvingAgainstBaseURL: false)
        return components?.queryItems?.first(where: { $0.name == "id" })?.value
    }
}

The key here is not to leave the view empty while wallpaperID resolves. URL parsing runs in the instant after launch, so ClipRootView should show a loading state first and switch to the target image the moment the ID arrives. That few-hundred-millisecond design determines how fast the App Clip feels.

Why insist on URL launches? Because the value of an App Clip is opening with context. The app does not merely start; the specific wallpaper the scanned QR points to is already open. Passing that context is the job of the URL parameter.

Declaring appclips in apple-app-site-association

For URL launches to work, the domain-side declaration and the App Clip's Associated Domains entitlement have to match.

In the App Clip target's Associated Domains, register the domain with the appclips: prefix.

appclips:example.com

On the server, place a JSON file with an appclips key at https://example.com/.well-known/apple-app-site-association.

{
  "appclips": {
    "apps": ["ABCDE12345.com.example.Wallpaper.Clip"]
  }
}

ABCDE12345 is your Team ID and com.example.Wallpaper.Clip is the App Clip's bundle ID. Serve this file as Content-Type: application/json with no redirects. If these do not line up, scanning the QR just opens Safari instead of the App Clip. I once mistyped a single character in this bundle ID and spent half a day chasing "why does it keep falling back to Safari." Suspect this mapping first.

Choosing the launch source

The same URL feels different depending on the entry point you launch it from.

If you are trying this for the first time as an indie developer, I would start with an App Clip Code. Apple's provided design itself signals "hold your phone here and something happens" — it needs less explanation than a QR code.

Handing App Clip state off to the full app

A user who thinks "I want to see more" moves from the App Clip to installing the full app. If you throw away the state they touched in the Clip, they start over after installing. You need a handoff.

The foundation of that handoff is an App Group. Put the full app and the App Clip in the same App Group and pass data through the shared container.

struct ClipHandoff {
    static let suite = "group.com.example.Wallpaper"
 
    static func store(previewedID: String) {
        let defaults = UserDefaults(suiteName: suite)
        defaults?.set(previewedID, forKey: "lastPreviewedID")
        defaults?.set(Date(), forKey: "clipHandoffDate")
    }
}

On first launch the full app reads this value and opens the wallpaper the user had been viewing in the Clip. "That wallpaper I just tried" appearing right after install reduces drop-off.

For more sensitive state, such as authenticated information, use a shared Keychain. Share the Keychain access group between the full app and the App Clip and store with a matching kSecAttrAccessGroup. The App Group holds ordinary data; the shared Keychain holds secrets that are safe to hand over.

Note that the App Group container survives for a while even after the App Clip is removed, but it is not permanent storage. Design the handoff as "read once, on first launch," and always provide a fallback on the full-app side for when the value is absent.

Deciding what the App Clip will not do

The most effective decision in App Clip design is not what to add but what to leave out. App Clips deliberately lack several capabilities.

Billing and full membership signup are the full app's job. Attempting them in the App Clip inflates both size and complexity, and you bounce off the 15 MB wall. To move a user from the App Clip to the full app, use SKOverlay to recommend the download without interrupting the flow.

Ephemeral notifications are worth remembering. An App Clip can send notifications for up to eight hours without asking for persistent permission. You can use this for a restrained nudge — "liked the wallpaper you previewed? here it is" — delivered once, a few hours later. Restraint is what keeps it tasteful.

Checking before you ship

For local testing, set the _XCAppClipURL environment variable in your Xcode scheme to feed a real launch URL in and verify behavior. Before you print a QR code, run through the parameter variations and confirm each one goes straight to the correct screen.

When you publish, registering an Advanced App Clip Experience in App Store Connect lets you show a distinct card — title, image, action — per specific URL. Starting with only the default experience and adding per-URL cards after you see the response was more than enough.

Even with Rork Max producing the underlying Swift, the heart of an App Clip is the "work outside the app" — splitting targets, declaring domains, wiring the handoff. Generated code is only a starting point. If you verify the wiring beyond it one step at a time, in the order laid out here, you should reach a path where the core of your app opens within seconds of a scan.

I hope this helps with your own implementation, and thank you for reading.