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.

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.

I downloaded the beta iOS 27 and I’m still on the waitlist, as are a whole bunch of other people. Is there like a bug of people not getting past the new Siri waitlist?

Hello, the only way to make Siri AI pick up my intent, or action on my intent + entity is that if BOTH use an schema? For example, I have an intent that adopts a schema, but my entity doesn't. That means Siri AI can't do anything with my intent? What if neither use a schema? Siri AI can't do anything with it? I'm asking because schema seems limited to only few domains which I'm not sure how I'll integrate with my apps.

I'm trying to associate a Core Spotlight item with an AppEntity during indexing by calling CSSearchableItemAttributeSet.associateAppEntity(_:priority:). However, every time I do so, I get the following warning in the console: {CSInlineDonation[async]: "my.app.bundle.identifier" add-update-items:1 delete-items:0}: Failed to request donation Error Domain=CSIndexErrorDomain Code=-1000 "Failed to request donation" UserInfo={NSDebugDescription=Failed to request donation, NSUnderlyingError=0x143f54ae0 {Error Domain=com.apple.CascadeSets.Set Code=3 "Access denied (<BMResource: set/App.Intents.IndexedEntity [CCSetDescriptor - key: sourceIdentifier value: my.app.bundle.identifier]>)" UserInfo={NSLocalizedDescription=Access denied (<BMResource: set/App.Intents.IndexedEntity [CCSetDescriptor - key: sourceIdentifier value: my.app.bundle.identifier]>), NSUnderlyingError=0x143f54ba0 {Error Domain=BMAccessErrorDomain Code=11 "Failed to prepare resource" UserInfo={NSLocalizedDescription=Failed to prepare resource}}}}} The relevant code is: let attributeSet = CSSearchableItemAttributeSet(contentType: .audiovisualContent) let appEntity = VideoAppEntity(...) attributeSet.associateAppEntity(appEntity) The Spotlight item itself is indexed successfully, but the associateAppEntity call appears to fail with an "Access denied" error related to App.Intents.IndexedEntity. Has anyone encountered this before? Are there additional entitlements, App Intents configuration requirements, or indexing prerequisites needed for associateAppEntity(_:priority:) to work correctly?

Are there specific Entitlements (com.apple.security.temporary-exception.files.absolute-path.read-write or network exceptions) required to allow App Intents to talk to local UNIX sockets or loopback interfaces (127.0.0.1) without triggering sandbox violations?

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.

I'm trying to understand the intended relationship between OpenIntent and the new .system.open App Intent schema introduced in iOS 27. From the documentation: OpenIntent (available since iOS 16) is described as an intent that opens an associated item. iOS 27 introduces the .system.open schema, which also appears to represent opening an entity or piece of app content. My questions are: For an app that supports iOS 27+, is .system.open intended to replace OpenIntent, or do the two serve different purposes? For apps that support both iOS 26 and iOS 27+, is the recommended approach to have two structs that implement the same opening logic, one with @AppIntent(schema: .system.open) and the other implementing the OpenIntent protocol? Thanks! References: open protocol OpenIntent

The documented template for @AppEntity(schema: .messages.message) at Integrating your messaging app with Apple Intelligence and on the MessagesEntity.message reference page shows: var reaction: <#ReadReaction#>? with <#ReadReaction#> rendered as a placeholder (the Xcode placeholder syntax). A natural reading is "fill in your own type that you want to use here". I tried several: Tapback? where Tapback is @AppEnum(schema: .messages.customReaction) MessageReaction? (same, renamed) MessageReaction? with manual AppEnum conformance (no schema decoration) AttributedString? AttributedString (non-optional) field omitted entirely Each variant produced one of: error: Property 'reaction' type does not match required AppSchemaEntity property type 'ReadReactionCases:(Schema<Tapback> | AttributedString)' error: Required AppSchemaEntity property 'reaction' must be optional error: Missing required property 'reaction' from AppSchemaEntity 'messages.message' The phrase ReadReactionCases:(Schema<Tapback> | AttributedString) is opaque — ReadReactionCases isn't a public type, Schema<Tapback> isn't constructable from outside, and the documentation doesn't mention @UnionValue in this context. The actual working pattern, which I only found by downloading the UnicornChat sample and reading MessageEntity.swift, is: @UnionValue enum MessageReaction: Sendable { case customReaction(CustomReaction) } @AppEnum(schema: .messages.customReaction) enum CustomReaction: String, AppEnum { case sticker static let caseDisplayRepresentations: [Self: DisplayRepresentation] = [ .sticker: "Sticker" ] } Two suggestions: Update the schema-template comment in the docs to either name MessageReaction explicitly with a @UnionValue annotation, or include a one-line note: "The reaction field is a @UnionValue enum wrapping the customReaction schema enum — see UnicornChat sample." The current placeholder <#ReadReaction#> plus the prose suggesting "you can generate the properties... with the @AppEntity(.messages.message) Swift macro" reads as if the developer just supplies any AppEnum-conformer. Improve the diagnostic. Property type does not match required AppSchemaEntity property type 'ReadReactionCases:(Schema<Tapback> | AttributedString)' is unhelpful because ReadReactionCases doesn't appear in any reachable type. Either rename to something developer-facing, or include a fix-it that suggests @UnionValue. iOS 27.0 beta, Xcode 27 beta, macOS Tahoe 26.4.

Our app already has a huge set of App Intents and Entities. Conceptually, our entities and intents matches well to the existing schemas (like the Notes schema). But because we have existing intents, we ran into two problems: Our existing intents/entities used different property names in the past and some properties are slightly different then the schema. Our existing intents are already used on older Versions of macOS / iOS. But the schema domain is only available on OS27 and later. What can we do to adopt the schema? Should we just duplicate all Intents / Entities and mark them as isAssistantOnly and limit their availability to OS27 and later?

For intents that return complex markdown, code snippets, or structured layouts, what are the rendering capabilities and resource constraints of custom SwiftUI views returned via Snippet inside the Siri voice overlay? Are interactive controls (like buttons, copy-to-clipboard, or scroll views) supported inside the Siri-overlay SwiftUI container?

Hi, I have an existing app with AppEntities defined, that works on iOS17+. The AppEntities also have EntityPropertyQuery defined, so they work as 'find intents'. I want to use the new @AssistantEntity which is iOS18+ where possible, while supporting the previous versions. What's the best way to do this? For e.g. I have a 'log' AppEntity: @available(iOS 17.0, *) struct CJLogAppEntity: AppEntity { static var defaultQuery = CJLogAppEntityQuery() .... } struct CJLogAppEntityQuery: EntityPropertyQuery { ... } How do I adopt this with @AssistantEntity(schema: .journal.entry) for iOS18, while maintaining compatibility with iOS17? I don't want to include two different versions of the same AppEntity. Would it just with with the correct @available annotations on both entities?

I’m using SwiftData in my app and would like to support the standard „Find“ Shortcut. What is the best way to use the EntityPropertyQuery’s entities(matching: mode: sortedBy: limit:) function with SwiftData? I’m currently using a Swift Package called CompoundPredicate to construct my predicates based on the QueryProperties and the SortingOptions. I know that SwiftData started to support compound predicates with macOS 14.4/iOS 17.4 or later. But from what I understand they are not dynamic and are validated at compile time. What is a native way to handle this dynamic predicate case of App Intent fetches?

Do apps like Files, Safari, and Finder provide on screen data on request? I've got an entity that implements transferable, but Siri is consistently telling me that it is unable to export data from Files, Safari and photos, and does not seem to want to construct my entity. (it's an @PhotoAsset entity, and I've implemented @createAssets as well.) Is that true at the moment that Siri cannot read data from those apps? I'm not sure if this is a bug or a feature.

Any guidance for migrating legacy AppIntents that are nearly identical in functionality to AppSchema app intents? I want to avoid duplicate intents (old vs new) showing up in Shortcuts.

Hello, I'm still working on my @addToAlbum schema implementation, and I'm exploring how multiple entities could be "destinations" to the intent. I considered using a @UnionValue for this, but I'm running into compiler difficulties trying to get a @UnionValue to conform to @AppEntity(schema: .photos.album) Am I out of luck on a Unionized "target" for the add-to-album intent?

During the keynote, we saw an amazing example of Siri using Visual Intelligence to identify items in the user's physical space and make inferences based on their size. Do 3rd party apps have the ability to perform this same, or similar actions? For example: User loads a photo of an item or product and clicks a button that says 'Find Item In My Space'. Apple Intelligence is then used to analyze the user's surroundings, and notify the user if the item is present or not present, along with some positional or physical context. Response is shown on the user interface as text, "This item is in your room, 1 meter to your right." Goal: Developers currently can not access the Passthrough Camera on Apple Vision Pro to run AI/ML vision processing models on, for privacy reasons. If Apple Intelligence can look through the camera for the developer, in a privacy-preserving, isolated black box, without providing the image texture to the developer in any way, the user can make use Visual Intelligence features based on their physical surroundings without sacrificing their privacy. Purpose: Visual Intelligence is a key feature for that exemplifies the benefits of Spatial Computing, and examples like the one shown in the Keynote are a perfect use-case for the medium. Since Siri now has this capability, users will come to expect that all apps across VisionOS will be able to perform the same kinds of actions. Developers don't generally want or need direct access to the images of a user's surroundings, and having a local/private method of processing these requests is ideal both for developers concerned with data privacy management and users concerned with developers having too much access to their surroundings. Wearable devices with cameras are a foundational accelerator to users adopting AI in useful ways for their daily life. It is the most natural way to communicate with AI about what is relevant to you at any given time, removes the friction/difficulty of manually scanning good data for AI inferencing, and brings purpose to wearing this class of device every day. As these devices become more common and capable, data privacy becomes even more important. Users will need reassurance that the devices they choose to wear will only have access to observe their surroundings when they choose to allow it, while retaining the capability to use the powerful features that make them worthwhile. Accessibility: Using Visual Intelligence is an extremely powerful accessibility tool (for example; for individuals who have low vision), and can meaningfully improve quality of life. Various applications beyond Siri AI can be designed by developers with very specific inferencing capabilities powered by AI. The future of Visually Intelligent apps should have intentional, unique purposes that users can choose to incorporate in their lives. This will not be a one-size-fits-all Visual Intelligence approach, and will require specific design, training and development to create meaningful capabilities. If this is already possible, amazing! Any resources to learn more would be greatly appreciated. If this is not yet possible, please let us know what we can do to encourage Apple to consider it. Thank you.

Does the App Intents framework expose the user's active spoken Siri locale (e.g., ja-JP, fr-FR) directly within the perform() context, or must the extension rely on the system's global locale setting? If a user switches Siri's language dynamically, how is that locale string propagated to the intent execution block?

When using the .photos.asset schema for an AppEntity conforming to IndexedEntity, is there a way to trigger the rich grid layout in Spotlight results that native apps like Photos and Messages currently utilize?

When implementing @AppIntent(schema: .photos.createAssets) in my app I can accept files to import as assets into my app. Therefore I would expect be able to use this in Shortcuts and pass in a selected file to my createAssets intent. For example using the Files app Select Files action and pass the selected files on to my photos.createAssets action. However doesn't seem to be possible in any way. The only thing I can do in Shortcuts is select a file for the create assets action at the time I make the shortcut. Which removes all flexibility. Is this a bug or a missing feature? Or am I missing something how to set this up correctly? I've been testing this with the new "Integrating your photo app with Apple Intelligence" Apple Sample and it's not working with that in any way. FB23066510