Exploring interactive snippet intents

Apple’s introduction of interactive snippets with App Intents(opens in a new tab) in iOS 26 at WWDC25 introduced a new level of interactivity for apps outside of their main interface. This means users can now interact with your app’s features from system-level experiences like Siri and the Shortcuts app, or even directly from Spotlight on a Mac, without needing to open the app itself. As the Advances in App Intents(opens in a new tab) WWDC session explains, snippets let your app “display tailored views with your App Intents, either to ask for confirmation or display a result” and you can “now bring those snippets to life with interactivity.” For a more detailed technical overview, refer to Displaying static and interactive snippets(opens in a new tab) in Apple’s official documentation.

This session sparked my interest: What are the practical limits of this interactivity? Could we, for instance, build a complex, multistep flow that guides a user through a process entirely within a snippet? This blog post details a short exploratory adventure to answer that question, along with the learnings and patterns I discovered for creating seamless user experiences with snippet intents.

The experiment: A postcard creation wizard

In this scenario, I created a fictitious app that allows users to create a simple postcard to share or export for printing. This process involves several steps within the app. For App Intents, the goal was to build a wizard that would guide the user through creating the postcard, step by step, without ever needing to open the main app. The intended flow was:

1. Start with a “Create Postcard” intent.
2. Interactively prompt for a background image.
3. Prompt for a front image.
4. Ask the user to input a greeting message.
5. Ask for the sender’s name.
6. Show a final preview and offer to export from within the app.

This seemed like a perfect test case for the new interactive features in App Intents.

For those not familiar with App Intents, this is a basic structure of one:

struct MyIntent: AppIntent {
    static let title: LocalizedStringResource = "My Intent"

    // A required value the user must supply.
    // If a default value is not provided, the system will prompt for it.
    @Parameter(title: "My Parameter")
    var myParameter: String

    // Any dependencies your intent requires at runtime.
    // Register it with `AppIntentDependencyManager` on launch and
    // the system will inject it automatically.
    @Dependency var dataService: DataService

    // This is the main method that is called when the intent is invoked.
    func perform() async throws -> some IntentResult {
        // Perform the intent logic.
    }
}

While it’s possible to define CreatePostcardIntent with multiple @Parameter declarations to gather all required data at once, this approach presents the user with an inflexible and overwhelming flow, which would defeat the purpose of this experiment. For a better user experience, I opted for an interactive multistep wizard, enabling the user to observe their progress and make changes similar to the flow in the app.

This pattern not only makes the process more approachable, but it also enables dynamic flow control, where subsequent steps can be altered based on previous inputs.

Simulating a wizard: The requestConfirmation chain

The key to creating this sequential, wizard-like flow is the requestConfirmation(actionName:snippetIntent:)(opens in a new tab) method. This is a new method introduced in iOS 26 with the latest App Intent framework that can be invoked within the body of any perform() method of an app intent. This method is asynchronous and waits until the user completes the confirmation action to proceed to the next line of code. By chaining these requests within the perform() method of our initial CreatePostcardIntent, we can present a series of snippets, one after another, guiding the user through each step.

Here’s how the CreatePostcardIntent is structured to kick off this process:

struct CreatePostcardIntent: AppIntent {
    static let title: LocalizedStringResource = "Create New Postcard"

    @Parameter(title: "Title", description: "The title of your new postcard")
    var title: String

    @Dependency var dataStore: PostcardDataStore

    @MainActor
    func perform() async throws -> some IntentResult {
        // Create the postcard document.
        let postcard = PostcardDocument(title: title)

        // Save to the data store.
        try await dataStore.addPostcard(postcard)

        // Start the interactive flow.
        try await requestConfirmation(
            actionName: .continue,
            snippetIntent: AddBackgroundImageSnippetIntent(postcard: postcard.toEntity)
        )

        try await requestConfirmation(
            actionName: .continue,
            snippetIntent: AddFrontImageSnippetIntent(postcard: postcard.toEntity)
        )

        try await requestConfirmation(
            actionName: .continue,
            snippetIntent: AddGreetingTextSnippetIntent(postcard: postcard.toEntity)
        )
        // We omit the `requestConfirmation` for the sender information and final preview steps for reasons that will be discussed later.
        return .result()
    }
}

The CreatePostcardIntent perform() method is where the interactive flow is initiated. After creating the postcard document, it starts the interactive flow by calling requestConfirmation() with the first snippet intent. Once the user has completed the first interactive step, the system will move to next request until the user has completed all the steps within the interactive flow.

Here is the basic structure of a SnippetIntent:

struct AddBackgroundImageSnippetIntent: SnippetIntent {
    static let title: LocalizedStringResource = "Add Background Image"

    @Parameter var postcard: PostcardEntity
    @Dependency var dataStore: PostcardDataStore

    func perform() async throws -> some IntentResult & ShowsSnippetView {
        // Fetch the latest state.
        guard let currentPostcardDocument = await dataStore.getPostcard(by: postcard.id) else {
            throw PostcardError.notFound
        }

        return .result(
            view: BackgroundImageSelectionView(postcard: currentPostcardDocument)
        )
    }
}

Consider the following SnippetIntent protocol:

protocol SnippetIntent : AppIntent where Self.PerformResult : ShowsSnippetView

It requires the perform() method to return a result conforming to the ShowsSnippetView protocol. AppIntent provides a convenient method to return an implementation of ShowsSnippetView with the .result(view:) method. This method takes a SwiftUI view as its parameter, which will be rendered in the snippet. It’s within this SwiftUI view that you can implement the interactive elements of your snippet.

This works perfectly for the first few steps where the user interaction is simple. This is because of the fundamental nature of snippet interactivity.

The core of snippet interactivity: Intents all the way down

My first attempt at testing interactivity involved using a standard SwiftUI Button with an action closure and a TextField to capture user input. However, I found that while the UI elements rendered, they were completely unresponsive.

What I learned: Interactivity is intent-driven

Direct manipulation of UI elements and local state changes within a Snippet View aren’t supported in the way they are in a standard SwiftUI view. The entire interaction model for snippets is built on the App Intents framework itself.

• Buttons — To trigger an action, you must use the Button(intent:label:) initializer. The system makes this button interactive, and when tapped, it performs the provided AppIntent. Any other Button initializer will result in a non-interactive UI element.
• User input — Elements like TextField or Toggle with local @State bindings aren’t interactive. To get text input from the user, you must trigger another AppIntent designed to request that input through its parameters.

This is a fundamental shift from typical UI development. Instead of thinking about view state, you must think about a state machine driven by a series of chained intents.

An example of this is how the postcard wizard handles image selection. Both BackgroundImageSelectionView and FrontImageSelectionView present a Generate button to allow users to pick randomly from a set of preexisting images for the postcard:

struct BackgroundImageSelectionView: View {
    let postcard: PostcardDocument

    var body: some View {
        VStack(spacing: 20) {
            ImageSelectionHeader(...)
            ImageProgressIndicator(postcard: postcard)
            ImagePreview(...)

            HStack(spacing: 12) {
                Button(intent: SelectRandomImageIntent(postcard: postcard.toEntity, surface: .back)) {
                    ActionButtonLabel(title: "Generate", style: .primary)
                }
                .buttonStyle(.plain)
                //...... Select Custom Image Button
            }
        }
    }
}

Tapping this button executes SelectRandomImageIntent. This intent’s perform() method is where the logic resides. It gets a random image, updates PostcardDocument in the data store, and then, most importantly, calls reload() on the associated SnippetIntent:

struct SelectRandomImageIntent: AppIntent {
    static let title: LocalizedStringResource = "Select Random Image"

    @Dependency var dataStore: PostcardDataStore
    @Dependency var imageService: PostcardImageService

    @Parameter var postcard: PostcardEntity
    @Parameter(default: .back)
    private var surface: PostCardSurface

    init() {}

    init(postcard: PostcardEntity, surface: PostCardSurface) {
        self.surface = surface
        self.postcard = postcard
    }

    func perform() async throws -> some IntentResult {
        guard var currentPostcard = await dataStore.getPostcard(by: postcard.id) else {
            throw PostcardError.notFound
        }

        // Add random background image.
        currentPostcard[keyPath: surface == .back ? \PostcardDocument.backImageData : \.frontImageData] = imageService.getRandomImage()
        currentPostcard.modifiedDate = Date()

        try await dataStore.updatePostcard(currentPostcard)

        // Reload the current snippet.
        surface == .back ? AddBackgroundImageSnippetIntent.reload() : AddFrontImageSnippetIntent.reload()

        return .result()
    }
}

The reload() method — which is a static function declared on SnippetIntent — is another new addition to App Intents in iOS 26. It’s the key to updating the snippet’s view. As the WWDC session on snippet intents explains, when an interaction with a snippet completes, the system uses the original SnippetIntent to trigger an update. Calling reload() explicitly tells the system to start this update cycle immediately. The system refetches any AppEntity parameters and then runs the perform() method of the SnippetIntent again, which in turn rerenders the SwiftUI view with the new data. This is why the perform() method of a SnippetIntent must be lightweight and free of side effects, as it’ll be executed multiple times throughout the snippet’s lifecycle. This reload() method is what gives SnippetIntent its interactive feel.

Supporting intents like SelectRandomImageIntent is available in the Shortcuts app by default, allowing users to update parts of a postcard, such as its background or greeting text, without running the entire wizard. While this offers users more flexibility, you can restrict app intent visibility to your defined context by setting the intent’s isDiscoverable property to false in its definition. This will hide the intent from the Shortcuts app, making it available only through your app’s specific flows.

Resuming the wizard: The OpensIntent pattern

The requestConfirmation chain is powerful, but it’s also brittle. The flow is broken the moment we need to perform an action that doesn’t simply confirm and move to the next step, such as gathering user input or selecting a custom image from the file system. This happens when we attempt to select a custom background or foreground image, as well as during the AddGreetingTextSnippetIntent and AddSenderInfoSnippetIntent steps.

For selecting a custom image from the user’s files, we need to request the system’s file picker view. Luckily, App Intents provides the IntentFile(opens in a new tab) entity, which represents an on-disk file or file-based resource. To trigger the file picker, we once again use the Button(intent:) pattern in our snippet view:

struct FrontImageSelectionView: View {
    let postcard: PostcardDocument

    var body: some View {
        VStack(spacing: 20) {
            FrontSelectionHeader()
            FrontProgressIndicator(postcard: postcard)
            FrontImagePreview(postcard: postcard)

            HStack(spacing: 12) {
                //..... Select Random Image Button.
                Button(intent: SelectCustomImageIntent(postcard: postcard.toEntity, surface: .front)) {
                    ActionButtonLabel(title: "Custom", style: .secondary)
                }
                .buttonStyle(.plain)
            }
        }
    }
}

This button triggers SelectCustomImageIntent. The key is the @Parameter of type IntentFile within this intent. Because this parameter is required and not yet provided, the system presents a file picker dialog to the user:

struct SelectCustomImageIntent: AppIntent {
    //...
    @Parameter(
        title: "Image File",
        description: "The file of the image",
        supportedContentTypes: [.jpeg, .png, .heic, .image]
    )
    var imageFile: IntentFile
    //...

    func perform() async throws -> some IntentResult & OpensIntent {
        guard var currentPostcard = await dataStore.getPostcard(by: postcard.id) else {
            throw PostcardError.notFound
        }

        // Set the image data for the correct surface (front or back).
        currentPostcard[keyPath: surface == .back ? \PostcardDocument.backImageData : \.frontImageData] = imageFile.data
        currentPostcard.modifiedDate = Date()

        try await dataStore.updatePostcard(currentPostcard)

        // Hand off using `OpensIntent` to resume the flow from the correct stage.
        // We'll explore the `EditPostcardIntent` in detail shortly.
        return .result(opensIntent: EditPostcardIntent(postcard: currentPostcard.toEntity, stage: surface == .front ? .frontImage : .backgroundImage))
    }
}

Once the user selects an image, the perform() method of SelectCustomImageIntent is executed, and it updates the postcard document with the new image data. However, this action has broken the original requestConfirmation chain.

To solve this, the intent hands off control using the OpensIntent pattern. After saving the new image, SelectCustomImageIntent returns an OpensIntent(opens in a new tab) result. The OpensIntent result allows the result of one intent to open another intent, basically handing over intent flow to the new intent — which, in this case, is EditPostcardIntent — ensuring the wizard can resume.

For collecting user text input, since we can’t place an interactive TextField in the snippet view, we must again use the Button(intent:) + OpensIntent pattern. GreetingTextView has a button that triggers a SetGreetingTextIntent:

Button(intent: SetGreetingTextIntent(postcard: postcard)) {
    HStack {
        Image(systemName: "wand.and.stars")
        Text("Add Greetings")
    }
}

This SetGreetingTextIntent is designed to request text input from the user via a required @Parameter. When this intent is triggered, the system presents a dialog to request text input. When the user provides the text, the intent saves the data and hands off control to EditPostcardIntent, as we did above:

@Parameter(title: "Greeting Text") var greetingText: String

func perform() async throws -> some IntentResult & OpensIntent {
     guard var currentPostcard = await dataStore.getPostcard(by: postcard.id) else {
     throw PostcardError.notFound
   }

   // Update greeting text.
   currentPostcard.greetingText = greetingText
   currentPostcard.modifiedDate = Date()

    try await dataStore.updatePostcard(currentPostcard)
    return .result(
        opensIntent: EditPostcardIntent(postcard: currentPostcard.toEntity, stage: .greetingText)
    )
}

The EditPostcardIntent now has the responsibility of getting the wizard back on track. It acts as a state machine, inspecting the postcard’s currentStage or a passed-in stage to figure out where the user left off, and then reinitiates the requestConfirmation chain from the correct step.

It’s worth noting that the current step is always derived from the data model. The PostcardDocument computes its currentStage based on which fields are filled (e.g. if images are set but greetingText is empty, the stage is .greetingText). This avoids storing state in the intent, ensuring consistency, since intents may be invoked multiple times or from different places:

struct EditPostcardIntent: AppIntent {
    //...
    @Parameter(title: "Postcard")
    var postcard: PostcardEntity

    @Parameter(title: "Postcard Stage", description: "Stage to resume editing from")
    private var currentStage: PostcardStage?

    @MainActor
    func perform() async throws -> some IntentResult & OpensIntent {
        var stage = currentStage ?? postcard.currentStage
        while stage != .complete {
            try await resumeFrom(stage: stage)
            stage = stage.nextStage
        }
        return .result(opensIntent: ExportPostcardIntent(target: postcard))
    }

    private func resumeFrom(stage: PostcardStage) async throws {

        switch stage {
        case .backgroundImage:
            try await requestConfirmation(
                actionName: .continue,
                snippetIntent: AddBackgroundImageSnippetIntent(postcard: postcard)
            )
        case .frontImage:
            try await requestConfirmation(
                actionName: .continue,
                snippetIntent: AddFrontImageSnippetIntent(postcard: postcard)
            )
        case .greetingText:
            try await requestConfirmation(
                actionName: .continue,
                snippetIntent: AddGreetingTextSnippetIntent(postcard: postcard)
            )
        case .senderInfo:
            try await requestConfirmation(
                actionName: .continue,
                snippetIntent: AddSenderInfoSnippetIntent(postcard: postcard)
            )
        case .complete, .preview:
            try await requestConfirmation(
                actionName: .share,
                snippetIntent: PostcardCompleteSnippetIntent(postcard: postcard)
            )
        }
    }
}

Completing the flow: Sender information and the final preview

The same pattern used for the greeting text is repeated when gathering the sender’s information. The AddSenderInfoSnippetIntent presents a view with a button that triggers the SetSenderInfoIntent. This intent, in turn, requests the sender’s name via a @Parameter, updates the postcard, and then hands off to the EditPostcardIntent to continue the flow.

Once all the necessary information has been gathered, EditPostcardIntent finally presents PostcardCompleteSnippetIntent. This snippet doesn’t collect any more input. Instead, it displays a final preview of the finished postcard, along with buttons to either export the postcard by opening the app or cancel. This serves as the final result of our interactive wizard.

Conclusion: Key takeaways from the snippet intent journey

This exploration into interactive Snippet Intents has been enlightening. It’s clear that while you can’t just treat intents as miniature apps, the App Intents framework provides a robust and flexible system for creating rich, interactive experiences. The key is to embrace the intent-driven paradigm: Chain intents together using various techniques discussed above to create dynamic and responsive workflows. The postcard wizard is just one example, but the patterns discussed here can be applied to a wide range of use cases, opening up exciting new possibilities for how users can interact with our apps from anywhere in the system.

You can explore the full source code on GitHub(opens in a new tab).