Hi everyone, We are developing a live TV streaming app for tvOS that allows users to watch live channels, replay content, and manage cloud recordings. We are struggling to integrate Siri for a seemingly basic use case: switching the live TV channel by voice (e.g. "Hey Siri, switch to channel X on [our app]"). Here is what we have tried and observed: App Intents — we implemented custom intents, but Siri does not resolve them to our app for channel-switching requests. Shortcuts — we added Shortcuts support, but users have to explicitly configure them; Siri never proactively picks our app. In-app and out-of-app — the issue happens in both contexts. When the user asks Siri to switch to a channel, it either does nothing or suggests other applications, never ours. Our questions: Is there a specific INPlayMediaIntent configuration or domain required to handle live TV channel switching via Siri on tvOS? Is proper Siri integration for live TV gated behind the Apple Video Partner Program? If so, is there any public documentation or a path for apps outside the US to access it? Has anyone successfully implemented voice-driven live channel switching on tvOS outside of the Video Partner Program? Any guidance or pointers to relevant WWDC sessions would be greatly appreciated. Thank you.

Hi everyone, I’m trying to understand the current capabilities of App Intents and Siri when using custom intents and custom entities, without adopting one of Apple’s predefined app schemas. As an example, imagine I have a shopping app for shoes. I might have one intent that lists shoes available for sale, and another intent that can open a specific shoe in the app or add a specific shoe to favourites. What I’m trying to validate is whether Siri can support multi-turn, contextual follow-up requests in this kind of custom-intent-only setup. For example: User: “Show me the shoes available for sale.” Siri/App: returns a list of shoes. User: “Add the third one to my favourites.” Siri understands that “the third one” refers to the third shoe from the previous result list. This kind of follow-up seems to work in some Apple-defined domains. For example, a user can ask to list calendar events and then follow up with something like “open the third one in Calendar,” and Siri appears to understand the reference to the previous list item. My current understanding is that this kind of conversational context, ordinal reference resolution, and follow-up disambiguation may only be available when adopting one of Apple’s app schemas, where Siri has a richer understanding of the domain and entities. If an app only uses custom App Intents and custom App Entities, without adopting an Apple-defined schema, should we expect Siri to support this kind of multi-turn reference resolution? Or is each turn in the conversation which requires a custom intent invocation effectively handled more independently? I’d appreciate any clarification on whether this is expected to work, currently unsupported, or only available through schema-based integrations. Thanks

In the past, for any App Intent developers provide to the AppShortcutsProvider, there needed to be explicit phrases provided to trigger the AppShortcut from Siri -- and if the user try to trigger the Shortcut using a slightly different phrase then the Siri does not work. With Siri AI, will App Intents that don't fit any schemas work without needing every phrase to be explicitly programmed?

Filed as FB23652582. In Xcode 27 beta, this no longer compiles when the deployment target is below iOS 27: @available(iOS 18.0, *) @AppEntity(schema: .photos.asset) struct AssetEntity: IndexedEntity { ... } // error: 'asset' is only available in iOS 27.0 or newer The identical source compiles under Xcode 26. It looks like the @AppEntity(schema:) macro now resolves .photos.asset to a declaration annotated for iOS 27, whereas in Xcode 26 it resolved to the (now-deprecated) iOS 16 declaration. What seems off: the .photos.album entity in the same domain still builds fine at an iOS 18 deployment target — only .asset requires iOS 27. That asymmetry is what makes me think it may be an unintended availability change rather than a deliberate one. Has anyone else hit this? And is this intended — i.e. is .photos.asset now meant to be iOS 27+ only, or should it still be usable from apps that deploy to iOS 18?

I have a photo editing app that owns no photo library. I want a user viewing an image in another app (e.g. Photos) to say "filter this image in MyApp" and have Siri hand that on‑screen image to my intent. Targeting iOS 27. What I've tried, and the result in each case: • App Shortcut + @Parameter var image: IntentFile — Siri resolves my other parameters (a filter AppEnum) by voice, but never binds the image; the run fails. • @AppIntent(schema: .photos.setFilter) with a .photos.asset entity — never routes from Photos. • @AppIntent(schema: .system.open): OpenIntent with a custom AppEntity target — "Open this image in MyApp" just launches the app by name; perform() is never called, and the entity query never runs. My understanding from WWDC26 "Build intelligent Siri experiences with App Schemas" (session 240) and "Discover new capabilities in the App Intents framework" (session 345): • Cross‑app content transfer (Transferable + IntentValueRepresentation) seems limited to system value types (IntentPerson, PlaceDescriptor); IntentFile is not a _SystemIntentValue, so an image can't ride that rail. • Onscreen awareness (NSUserActivity.appEntityIdentifier, View Annotations) appears to expose only the foreground app's own content — which here is Photos, not me. Question: Is there a supported way for a third‑party app to receive another app's on‑screen image (vs. a contact/place) through Siri/App Intents today? If so, which API carries the pixels — an IntentFile parameter, @UnionValue, IntentValueQuery, something else — and what must the source app do to make it available? Or is asking "do X to this image in <third‑party app>" simply not supported yet outside Shortcuts?

Hello Team, I am writing to seek clarification regarding an issue I am encountering while integrating App Intents within my application. I have configured an App Intent designed to accept an IntentFile as a parameter for processing. When testing this functionality via the Siri interface, I attach the image file and provide the trigger phrase as expected. However, Siri does not seem to recognize or associate the attached image as the required IntentFile. Consequently, the interaction fails to proceed, and Siri continues to prompt me to select a file. Could you please advise if there is a specific configuration requirement or a known limitation regarding how Siri handles file attachments for IntentFile parameters? I would appreciate any guidance on whether this is an issue with my current implementation or if I am missing a necessary step in the setup process. Thanks & Regards Suresh

I've integrated my app with Visual Intelligence (iOS 26) using the semanticContentSearch schema. Image results are populated via an IntentValueQuery returning my entities, and the "More results" button is backed by an intent declared as: @available(iOS 26.0, *) @AppIntent(schema: .visualIntelligence.semanticContentSearch) struct ShowSearchResultsIntent { static let title: LocalizedStringResource = "Search products by image" static let openAppWhenRun: Bool = true var semanticContent: SemanticContentDescriptor func perform() async throws -> some IntentResult { /* deep-link into in-app search */ } } From WWDC25 (session 275) and WWDC26 (session 297) my understanding is that: the "More results" button is provided automatically by the system once this schema intent is adopted; returning an empty array from the value query lets the system show an empty response; my app appears as a result tab alongside other adopting apps, and the system decides the ordering based on the available image search providers on the device. I have a few questions about how much of this an app can control at runtime: "More results" button Is there any supported way to conditionally show or hide the system "More results" button at runtime (e.g., region, A/B test, server-driven feature flag)? Or is it strictly tied to the static presence of the semanticContentSearch intent? If IntentValueQuery returns an empty array, does the "More results" button still appear? Is there any API to suppress the button while keeping the schema intent declared? App result tab ordering How exactly does the system decide the order of the app result tabs? Is it based on relevance/similarity, app category, user behavior, or something else? Is there anything a developer can do to influence where their tab appears, or is ordering entirely system-controlled? App result tab presence / opt-out Once the integration is implemented, my app's tab appears automatically. Is there a supported way to conditionally opt out of appearing as a result tab at runtime (e.g., based on region or a feature flag)? Or is the only way to not appear to omit the integration at build time (or gate it by OS availability)? Thanks!

If I attempt to use a LongRunningIntent from a SwiftUI Button, using the Button(_:AppIntent:) control, I get the following errors: [LongRunningIntent <<E:<unknown>>>] No IntentContext available performBackgroundTask threw: noContext Intent failed to execute with error: LNPerformActionErrorCodeUnsupportedValueType It runs as expected when run from the Shortcuts app, but fails when run from a button within the app. Feedback ID (with sample app): FB23492034

Currently, I have spotlight entities show up when I search for them using Spotlight on iOS 27. These entities are things that are important for users, like campus buildings, accessible entrances, assignments, and more. However, after getting access to Siri AI, it seems that none of this information at all is available to Siri, yet all of it is sitting there in the spotlight index and viewable with a written query. I was told by an Apple Engineer that creating Indexed and EnumerableEntities, and indexing them via the App Intents framework, should expose information about these items to Siri, so if I query: "[Building name] in Ohio State" it would at least show me what the app has for that information. Presently, Siri uses the web for everything and doesn't pull in any spotlight information for my app, despite either creating wrapper entities or using the API associating with spotlight. With Siri AI, it would be so much more helpful for a disabled user to say "Orton Hall accessible entrance" and Siri to know that there's 1 accessible entrance indexed in spotlight in my app, and then show or open it, instead of querying the web or saying it can't answer the question. It has all available information already in spotlight to answer this question. Currently, as far as I'm aware, something like this simply doesn't work, unless your app conforms to the strict use cases of making reminders or calendar events, all of which aren't useful here. Can a Frameworks engineer please clarify precisely when and how IndexedEntities (paired with an a corresponding macro-annotated OpenIntent) eg: @AppIntent(schema: .system.open) struct OpenBuildingIntent: OpenIntent { @Parameter(title: "Building") var Building: BuildingEntity ... will or will not be visible using Siri AI? To me it seems I have wasted a lot of time porting actions within my app to App Intents, and viewable entities with AppEntity, only to have Siri not be able to use any of this information out of the box.

Hi everyone, I've submitted a Feedback request (FB23469644) asking to introduce a generic Transportation Journey schema for App Intents. At the moment, there doesn't seem to be a way to donate structured public transportation trips (train, flight, bus, ferry, etc.) to Siri's semantic index. While many travel apps already have rich journey data, there is no common semantic model that represents: Multi-leg journeys Departure and arrival stations/airports/stops Platforms, tracks, gates, terminals Scheduled and real-time departure/arrival information Delays and cancellations Ticket and reservation information This seems like a natural addition to the existing App Intents schemas and would enable Siri, Spotlight, and Apple Intelligence to better understand upcoming journeys across all transportation providers. If you're building a travel or mobility app and have encountered the same limitation, I'd appreciate hearing your thoughts. Any idea if the old Siri event suggestion API gets is indexed by Siri Semantic Index / Siri AI?

Hello, I’m implementing the AppIntents framework in my app. I want to translate the TypeDisplayRepresentation that is used in the Shortcuts app UI like in a DeleteIntent (see my feedback about this: FB23451186 for more context). In the “Accelerating app interactions with App Intents” sample code we can see that this is done using a .stringsdict file, as follows for the “Trail” key (singular and plural): <key>Trail</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@VARIABLE@</string> <key>VARIABLE</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>Trail</string> <key>other</key> <string>Trails</string> </dict> </dict> I want to use a String catalog instead of a .stringsdict file because all my strings are in a String catalog. I tried to migrate the AppIntents.stringsdict file manually but it failed with an error: “An error occurred when migrating AppIntentsSampleApp/Resources/AppIntents.stringsdict: This stringsdict cannot be migrated: Missing required key 'NSStringFormatValueTypeKey' inside 'Trail' -> 'VARIABLE’” So I manually added a NSStringFormatValueTypeKey like this in the .stringsdict file: <key>Trail</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@VARIABLE@</string> <key>VARIABLE</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>NSStringFormatValueTypeKey</key> <string>lld</string> <key>one</key> <string>Trail</string> <key>other</key> <string>Trails</string> </dict> </dict> And then I’ve been able to migrate the .stringsdict file into a String catalog. The string catalog looks like this after migration: "Trail" : { "extractionState" : "stale", "localizations" : { "en" : { "stringUnit" : { "state" : "translated", "value" : "%#@VARIABLE@" }, "substitutions" : { "VARIABLE" : { "formatSpecifier" : "lld", "variations" : { "plural" : { "one" : { "stringUnit" : { "state" : "translated", "value" : "Trail (Catalog)" } }, "other" : { "stringUnit" : { "state" : "translated", "value" : "Trails (Catalog)" } } } } } } } } This works, which is nice. But I tried to reproduce the same result by having a %#@VARIABLE@ in my LocalizedStringResource defaultValue like this: TypeDisplayRepresentation( name: LocalizedStringResource( "Flower", defaultValue: "%#@VARIABLE@", table: "AppIntents" ), numericFormat: LocalizedStringResource( "\(placeholder: .int) flower", table: "AppIntents" ) ) But the String catalog doesn’t support that apparently, I can’t get a “substitution” object in my catalog, so I have to manually do it using the source code which is not ideal and painful. Is there a way to support this kind of substitution with no actual plural token in the string as we can see for the %#@VARIABLE@ for Trail? Thank you, Regards, Axel

Hello, My (fictional) app has multiple app entities like a BookEntity and an AuthorEntity. There is a relationship between them: a book has an author. Because I implement the EntityPropertyQuery for the BookEntityQuery, it creates a “Find Book where...” intent. In this intent, I can filter the data by an author (AuthorEntity). But I can’t find a way to allow the user to select any author using the searchable modal usually presented to “choose” a parameter value from an intent for example. Right now, it shows: a menu with the suggestedEntities() authors if the AuthorEntityQuery implements this function. With no way to search even if the AuthorEntityQuery conforms to the EntityStringQuery. a menu with allEntities() authors if the AuthorEntityQuery conforms to EnumerableEntityQuery and does not implement the suggestedEntities(). With no way to search even if the AuthorEntityQuery conforms to the EntityStringQuery. nothing if suggestedEntities() is not implemented and allEntities() is also not implemented even if the AuthorEntityQuery conforms to the EntityStringQuery. So this means if I implement suggestedEntities(), my users have no way to choose any author not in the suggestions. It’s too limited. if I implement allEntities() but not suggestedEntities(), this could potentially be a lot of entities and it’s not always relevant because then the Shortcuts app with an AuthorEntity parameter will be created for allEntities(), and the UI with always show the full list of allEntities() when I have to pick an author (unless I build a specific DynamicOptionsProvider but this would mean I lose the suggestedEntities() for example. if I just conforms to EntityStringQuery, I can’t select any item at all for this filter (no menu to choose). You can check the attached sample code provided. I checked a bit other apps, for example the Photos app allows you to find a photo based on an album but it lists ALL the albums (which is a lot) with no way to search using string. I also check the Sofa app, it shows the list of SofaListEntity (which implements suggestedEntities() and conforms to EntityStringQuery and EntityQuery). It actually shows all the lists (confirmed by the developer) with no way to search. See attachements from the Sofa developer. Is there a way to support a search for a filter using a relationship conforming to the EntityStringQuery? Is there a way to specify a provider for a @Property of an entity like we can for a @Parameter? For example, I could provide a custom DynamicOptionsProvider for the @Property(title: “Author”) var author which would be independent from the AuthorEntityQuery used elsewhere (parameter intents + Shortcuts). Maybe you can suggest another way to implement this? Maybe I should not rely on a relationship but instead flatten the relationship in the BookEntity to add an “authorName” or “authorID”? I filed this feedback with a sample code: FB23453134 Thanks, Regards, Axel

Hello, I'm using a DeleteIntent in my app, but I can't get it to display "Delete {Books}" in the Shortcut apps. It always displays "Delete {Book}". It apparently uses the BookEntity typeDisplayRepresentation instead of using the intent entities parameter title ("Books") in the parameterSummary. For a "normal" AppIntent, the Shortcuts app uses the entities parameter title ("Books") in the parameterSummary. I filed a feedback: FB23451186 Regards, Axel

I'm seeing what appears to be different UISceneAppIntent behavior between iOS and Designed for iPad on macOS, and I'd like to confirm whether this is expected. I'm working on an iOS app that defines an AppIntent conforming to UISceneAppIntent from the AppIntents framework. The intent is handled by a scene delegate conforming to both UIWindowSceneDelegate and AppIntentSceneDelegate. On iOS, everything works as expected: If the app is launched for the first time from Shortcuts, the intent is available via connectionOptions.appIntent in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is called. However, when running the same iOS app on macOS in Designed for iPad mode, the behavior is different: If the app is launched from Shortcuts, connectionOptions.appIntent is always nil in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is never called, even though the application is successfully activated. Is this expected behavior? I noticed that the AppIntents framework explicitly marks both AppIntentSceneDelegate and UISceneAppIntent as unavailable on macOS: @available(iOS 26.0, tvOS 26.0, *) @available(macOS, unavailable) @available(watchOS, unavailable) public protocol AppIntentSceneDelegate : UISceneDelegate Since the app is running on macOS in Designed for iPad mode and still uses the iOS binary, I wasn't sure whether these scene-based APIs are expected to work in this environment or whether they are intentionally unsupported. Has anyone from Apple or the community been able to confirm whether this behavior is by design, or whether it should be considered a bug? I'd appreciate any clarification.

In my app, I adopt ‘App Intents’ and ‘App Entities’ for various items and actions in my app. These work in the Shortcuts app, and users can use Find Intents to lookup information or use the intents to act up on them, even though they don’t map on to any of the specific App ‘Schemes’ and ‘Domains’ that are listed. If I'm using just App Entities and Intents on their own, would these participate with the new Siri AI, without any additional work? For example, in my app, I have entities like Contacts, Tags, and ‘Visit Logs’. I have intents for 'create tag’, ‘add tags to a contact’, add a ‘Log’ to a 'contact' etc. These are specified in the AppShortcutsProvider list, but I have more than 10 intents. How would these work with the new Apple Intelligence and Siri? Or does Siri integration require AppSchema adoption?

Hello, I have an AppEntity with an EntityQuery that conforms to EnumerableEntityQuery by providing an allEntities() method. This creates a default "Find" action in the Shortcuts app for that entity, including automatic filtering on primitive properties such as dates and numbers. The entity has an AppEnum property. However, the "Find" action returns zero results when filtering by that property – even though the enum value is correctly displayed when using the "View" action on the same entity. Conforming to EntityPropertyQuery and manually defining comparators does fix the enum filtering, but it replaces all of the system-generated filtering, requiring me to reimplement comparators for every property I want to remain filterable. Is this the intended behavior, or is automatic filtering on AppEnum properties something that should be supported out of the box? Sincerely, Holger

I conform to @AppEntity(schema: .photos.album). I'm curious if I can steer how Siri thinks of these entities when the user speaks about them. While my app contains groups of images, they are not presented to the user as "albums". In fact "albums" from PhotoKit are used when creating these galleries. This distinction is important. The user is most likely to say "I want to open a gallery in " rather than "I want to open an album in " Is it possible to steer Siri into thinking of these AppEntities as galleries rather than albums? Similar to how IndexedEntity contains a CSSearchableItemAttributeSet ?

In visionOS 2, the system search displays the icon of each App Entity registered. It used to work up to visionOS 26 beta 7. But since visionOS 26 beta 8, visionOS 26.x , and still in the current visionOS 27 Beta 2 the system search no longer display the right icon. Instead it displays the icon of an AppShortcut declared by the source code which uses the AppEntities. This does not help the users to find the right AppEntity in a search with multiple results as they all have the same AppShortcut icon. This "bug" also make the search result differ from the experience with iOS and iPadOS which display each AppEntity icon. You can use the Apple sample to see this bug on visionOS 27 Beta 2 and 26. Accelerating app interactions with App Intents AppEntities are an important part of Apple Intelligence, the system integration is really important for a great user experience. FB19915478

I wonder how to apply multiple schemas to the same entity. Just to give an example: Let's say we have a typical shoebox application for note taking. Notes can be organized in hierarchical folders. For notes the note entity schema makes obviously sense. And for folders we need to apply the schema notes.folder, so this entity type can be used with the createNode and updateNote intent schemas. But, it would also make sense to use the file schema for folder entities, as it allows me to use the createFolder intent schema or deleteFile. Unfortunately, I can only apply one schema to one entity. So I can't declare a folder as note.folder and file.file simultaneously. I thought about using multiple entity types for the same entity to have somewhat multiple representations, but I can only assign a single app entity identifier to a view.

Hey, Running iOS 27 beta and have App Intents working in the shortcuts app. When I ask the exact query via Siri it seems to say it can't do that and asks me to open the app to do it manually. Is this expected behaviour? A bug? Anything I need to double check? The app doesn't map to a schema directly.