App Intents & Siri Q&A

My app is built around music albums. How would I support the utterance "open this in Apple Music" when a user is looking at an album in my app? Is a .userActivity with an associated appEntityIdentifier enough? If my AppEntity had the Apple Music ID in one of it's properties would the system figure it out? Or would I need a transfer representation too? This introduction of IntentValueRepresentation was confusing for me. It seems from the talk that maybe this is required to make this work, but doesn't seem like there is any relevant _IntentValue for my use case.

Say you have an App Entity representing an image. And an app intent that returns it as a value. Is there any way to define a compound transfer representation? For example, if the user wanted to create a Shortcut that sent a message or created a note with the image along with the image title as plain text. Last I attempted this, the system rendered a single compound image with the title baked in underneath the actual image, as opposed to the image followed by a text string underneath it.

We want to support voice workflows that require safety confirmations (e.g., 'Siri, prune my stale database caches' followed by Siri asking 'This will delete 42 entries, are you sure you want to proceed?'). How do we cleanly model multi-turn dialogs in Swift using AppIntent without forcing the user to re-trigger Siri? What is the correct way to throw dialog prompts or handle dynamic parameter disambiguation (e.g., if the user says 'Siri, check status' and multiple daemon instances are running, how do we return a list of choices to Siri to read out loud)?

I’m currently using ShowInAppSearchResultsIntent to open the app in a selectable view with the search results. The user can choose which view to pick via a @Parameter. Though with iOS 27 I can’t compile this intent anymore, because of this error: 'ShowInAppSearchResultsIntent' must only have a 'criteria' parameter What is the best practice to offer the same selection of the search view with iOS 27 and newer then? My Code import AppIntents @AppIntent(schema: .system.search) struct SearchAppIntent: ShowInAppSearchResultsIntent { static let searchScopes: [StringSearchScope] = [.general] var criteria: StringSearchCriteria // MARK: Parameters @Parameter(default: .loans) var target: SearchView? // MARK: Action Text static var parameterSummary: some ParameterSummary { Summary("Search \(\.$criteria) in \(\.$target)", table: "Shortcuts") } // MARK: Action @MainActor func perform() async throws -> some IntentResult { switch target { case .general, nil: // Open app search tab NavigationManager.shared.openAppSearch(with: criteria.term) case .contacts: // Open contacts tab NavigationManager.shared.openContactsSearch(with: criteria.term) } return .result() } }

Some of our intents involve initiating local-to-remote database synchronization (e.g., syncing local memory metrics to a remote MongoDB instance). This operation can take between 5 to 15 seconds depending on network conditions. What are the strict execution timeout limits for App Intents running in the background on macOS and iOS (especially when triggered via Siri without active UI)? If the operation exceeds the default limit, will Siri forcefully terminate the intent? How can we request background execution extension or hand off the work to a background download session/daemon while reporting progress back to Siri in real-time? Does the system support asynchronous yielding (Progress) so Siri can display a progress bar or status updates (e.g., 'Syncing 50%... Done') during execution?

Apple Music's Live Activity has instantly responsive prev/next/pause intents. Similar Buttons and Toggles on our Live Activity shimmer for a second or two as the LiveActivityIntent perform body executes light work in our main process, the content update is submitted and serialized, and that update finally renders. That makes our Live Activity a bit clunky. The delays also nixed some useful interactive feature ideas. The slow response is true even if our main process was running in the background with an active HKLiveWorkoutBuilder. Is this an expected limitation? Is there a strategy we should have taken to avoid this? (We do use optimistic animations via Toggle to soften the edges a bit.)

If you have an app that provides technical answers (similar to a LLM), is there AppSchemeDomain that's appropriate?

In some of our intents, we want the user to dictate a custom prompt or text body to be stored in the memory cache (e.g., 'Siri, add memory tag with content: Remember to invalid auth caches when schema bumps'). How can we define an AppIntent parameter that accepts open-ended dictation or arbitrary string blocks from Siri's speech-to-text translator? Are there length limits or language restrictions on string parameters parsed by Siri?

Hi, I have a list of contacts that I store in my app. Can I list all the contacts and their properties into the new Siri by adopting this schema? @available(iOS 27.0, *) @AppEntity(schema: .messages.messagePerson) struct CJPersonAppIndexedEntity: IndexedEntity { ... } It's not really part of the 'messages' domain, but is it correct to use? Also, if I have a concept of a 'task' and 'file' in my app? Can I use the .reminders domain and use .createreminder intent, and mix that 'reminders' and 'files' domains with the 'messages' domain, all in the same app?

In my plant watering app, I created a PlantEntity and a WaterPlantIntent that edits the plant to mark it as watered. PlantEntity conforms to AppEntity and IndexedEntity. I also created OpenPlantIntent that conforms to OpenIntent. My AppShortcutsProvider is implemented like so: struct ShortcutsProvider: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { return [ AppShortcut( intent: WaterPlantIntent(), phrases: [ "Water plant in \(.applicationName)", "Water \(\.$plantEntity) in \(.applicationName)" ], shortTitle: "Water Plant", systemImageName: "drop.fill" ) ] } } Now, when I search in Spotlight for a plant name, two results are shown but both are titled the name of the plant. The one in the App Name section just opens the plant in the app but the one in the Top Hit section actually performs the WaterPlantIntent! There's no indication that would occur. I expected it to be titled Water Plant Name so users know what shortcut is being run. Is there a way I can configure my code to show the proper title here?

I have an app that allows users to create charts and add series to them using AppIntents in Shortcuts. I couldn't find any AppSchemas that would match my entities in the official documentation. While "vibe coding" shortcuts, will Siri AI only access app intents through AppSchemas? If 1 is true, is there any alternative to AppSchemas to make AppIntents discoverable by Siri?

For schema conforming App Entities, does the synonyms API on DisplayRepresentation feed into Siri AI's natural language understanding of your app's entities?

At WWDC24, the guidance was that you could extend a schema conforming App Entity beyond its pre-defined shape with optional parameters, but that these would not be understood by Siri. In tandem, there was also CSSearchableItemAttributeSet properties but I don't recall how those were or were not understood by Siri. Could you please help clarify how these two related concepts work together going forward in terms of how entities are exposed across Spotlight, Shortcuts, and Siri.

For apps migrating from SiriKit to App Intents, is there a recommended way to test that an intent is actually discoverable by Siri AI — beyond just confirming the code compiles? Are there APIs to verify an intent is properly indexed and reachable via natural language? Divya Ravi, Senior iOS Engineer

Here are a variety questions around compatibility, some related to iOS 27 changes, some related to iOS / watchOS: Sometimes my AppShortcutProvider do not update properly. Do you a suggested series of actions to clean them up on the device after making changes? I have a lot of trouble getting watch apps to recognize shortcuts that I supply to them, and trigger phrases that work on the phone fail on the watch even when it hears all the words correctly. Do you have any suggestions for supporting watchOS? There are a number of .result() variants for AppIntents, and some are only compatible with iOS 26 / 27. Do you have any recommendations for how to offer support for iOS 18 devices too without completely sacrificing the new features especially in iOS 27? AppEntity(schema:) for iOS 27 greatly expanded its usefulness, but they are not backward-compatible. Is there a way to gate the usage of AppEntity(schema:) for just iOS 27 or gracefully degrade? How does the new Siri interact with AppShortcutProvider? Are they unnecessary as long as I have Intent Entities and Intents? Do they interfere?

In our application, we have dynamic records (sessions, workspaces, and logs) stored in a local SQLite database that is modified in real-time by a background command-line tool. We want Siri to resolve these as AppEntity types (e.g., 'Siri, show status of [Session Name]' or 'Siri, export log for [Project]'). Since EntityQuery requires returning list/suggested entities, how do we efficiently synchronize or query the external SQLite file from the App Intent extension? Are there file-locking or concurrency issues we should be aware of when the CLI tool is writing to the database while Siri is querying it? Is there a performance penalty or memory limit when returning thousands of dynamically generated AppEntity instances in suggestedEntities()? Should we implement custom indexing or virtual tables to support Siri's fuzzy name matching?

Is SiriKit now deprecated? And if so, how will that impact INAlternativeAppNames as it relates to app name synonyms in App Shortcuts?

Will Siri only invoke Schema-based Intents? Is there no chance of Siri invoking another short cut, or share sheet extension with an input that its found on screen?

It’s often desirable to implement AppIntents in an app extension, but under AppSchema this is more challenging because “on screen awareness” binds views to app entities. This creates a need to synchronize AppEntity data across the boundary between the main app and the app extension. What are the best practices for managing the required bidirectional data exchange? Are there good sample applications that illustrate how to do this cleanly?

For an AppIntent that creates an AppEntity via a long-running async task, does it make sense for the intent’s “perform” method to return a placeholder AppEntity and update it later via a donation, or is it best to make “perform” async and return only once the entity is completely resolved?