I would like to raise a platform-level question about the future relationship between Apple Intelligence, App Intents, iOS permissions, and third-party AI systems. I have been deeply invested in the Apple ecosystem for many years. One of Apple's greatest strengths is that iPhone, iPad, and Mac work together with very little friction. The other major strength is Apple's strong privacy and security model. Generative AI is now creating a new tension between those two strengths. On the Mac, users can explicitly grant AI tools relatively broad access to files, folders, and, in some cases, application controls. This has changed what non-technical users can accomplish. I am not a software developer, but with AI assistance I can now design workflows, create automation, work with structured data, and build tools on my Mac that would previously have required professional knowledge. In other words, AI has not merely made the Mac more efficient. It has expanded the capabilities of the user. This makes the restrictions on iPhone increasingly noticeable. The issue is not the computing power of the iPhone. Modern iPhones are extremely capable devices. The issue is that third-party AI systems cannot yet work with the user's personal context, application data, and device capabilities with the same degree of flexibility, even when the user explicitly wants to grant such access. My question is: Could iOS evolve toward a more general, user-controlled permission architecture for third-party AI agents? I am not suggesting unrestricted access to the device. I am suggesting a system in which users can explicitly grant narrow and persistent permissions to an AI provider or AI agent. For example: Allow read-only access to a specific folder. Allow search access to selected Notes or note categories. Allow access only to a particular Photos album. Allow calendar read access but not modification. Allow an AI to search Photos but never delete them. Allow routine read/search operations automatically, while requiring confirmation before modification, deletion, sending, purchasing, financial activity, or other sensitive actions. From a platform-design perspective, this could potentially be implemented as multiple layers: iOS defines the maximum permitted scope. The user explicitly chooses the resources and capabilities available to the AI. The AI provider is expected to operate within the minimum necessary scope. Sensitive or destructive actions require an additional confirmation boundary. Access can be reviewed, reduced, or revoked centrally by the user. This seems consistent with Apple's existing security philosophy rather than opposed to it. The goal would not be to give an AI "full access." The goal would be to create an OS-level capability model in which the user can safely delegate specific access and actions to AI. App Intents already provides a structured way for applications to expose actions and entities to the system. Apple Intelligence is also increasingly able to work with application capabilities and user context. The question is whether this model could eventually be extended into a broader framework for third-party AI systems. For example, rather than allowing ChatGPT, Claude, Gemini, or another model to directly inspect the device, iOS could remain the trusted intermediary. The AI could request a capability or a piece of context. iOS could evaluate: Which data is being requested? Has the user authorized this category? Is the request read-only or destructive? Does the request require confirmation? How much context should be disclosed? Should the AI receive raw data, structured data, or a filtered result? This would allow Apple to remain the security and permission authority while still letting users benefit from advanced external AI models. I believe this distinction is important. Apple does not necessarily need to expose raw device access to third-party models. Instead, Apple could expose a secure capability layer controlled by the OS and the user. This also raises a broader architectural question about Siri and Apple Intelligence. Does Siri itself need to become the most capable general-purpose AI model? Perhaps not. A possible architecture would be: Siri / Apple Intelligence understands user intent, manages personal context, controls permissions, identifies the appropriate application or data source, performs local or private operations where appropriate, and delegates advanced reasoning when needed. Third-party AI models provide advanced reasoning, planning, interpretation, generation, or domain-specific intelligence. iOS remains the trusted security boundary between the AI model and the user's personal environment. In such a system, Apple would not need to sacrifice privacy in order to support highly capable AI. It could instead become the platform that provides the safest interface between powerful AI systems and a user's personal digital environment. From a user-experience perspective, I believe this is becoming increasingly important. AI has made my Mac substantially more useful because it allows me to accomplish tasks that were previously beyond my technical ability. I would like that same expansion of capability on the iPhone. Today, the Apple ecosystem is seamless at the data and device level, but less seamless at the AI capability level. Mac can increasingly function as an AI-enabled working environment, while iPhone remains much more restricted. That difference may become more significant as AI agents become more capable. So my main request is: Please consider allowing iPhone users to grant third-party AI systems broader but carefully scoped access to device data and application capabilities. Not unrestricted access. Not a bypass around Apple's privacy model. Rather: user-controlled, granular, revocable, OS-mediated AI permissions. If Apple can provide that securely, I believe it could significantly improve the usefulness of iPhone while preserving the privacy and security principles that make the Apple ecosystem distinctive. I would be very interested to know whether App Intents, Apple Intelligence, or another future framework is intended to evolve in this direction.

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'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

Hello, I'm a EU-based developer. Our app is distributed worldwide. I'd like to clarify the following regarding Siri AI and EU: is Siri AI unavailable to users based in EU, or to apps based in EU. In other words, will my app developed in Europe work with Siri AI for US users? Or the fact that my app is developed in Europe excludes it from compatibility with Siri AI? Kind regards, Bruno

My intents and entities show up in Shortcuts, and my tests that use App Intents Framework pass. But I can't for the life of me figure out why Siri won't work. I'm trying phrases like "Add to my list in ". All I ever get from Siri is variations of "I can't add items directly to " or "I can't add items to your lists in ". Does anyone see any issues with the following? ( I've left out some of the AppEnum and Entity types for brevity, but these are the main ones) @AppIntent(schema: .reminders.createReminder) struct AddToListIntent { var title: String var list: ListEntity? var note: AttributedString? var isFlagged: Bool? var images: [IntentFile] var tags: Set<String> var urls: [URL] var dueDate: DateComponents? var recurrence: Calendar.RecurrenceRule? var locationTrigger: LocationTriggerEntity? var section: SectionEntity? func perform() async throws -> some ReturnsValue<ReminderEntity> { let newReminder = ReminderEntity(id: "foo", reminder: .init(name: title)) return .result(value: newReminder) } } struct Reminder { var name: String } @AppEntity(schema: .reminders.reminder) struct ReminderEntity { // MARK: Static static let defaultQuery = ReminderEntityQuery() // MARK: Properties let id: String let reminder: Reminder @ComputedProperty(title: "Title") var title: String { reminder.name } var note: AttributedString? { nil } var tags: Set<String> { Set() } var urls: [URL] { [] } var dueDate: DateComponents? { nil } var recurrence: Calendar.RecurrenceRule? { nil } var isCompleted: Bool { false } var isFlagged: Bool? { nil } var creationDate: Date? { nil } var completionDate: Date? { nil } var list: ListEntity var locationTrigger: LocationTriggerEntity? { nil } var displayRepresentation: DisplayRepresentation { .init(title: "\(title)") } // MARK: Query struct ReminderEntityQuery: EntityQuery, EnumerableEntityQuery { func entities(for identifiers: [ReminderEntity.ID]) async throws -> [ReminderEntity] { identifiers.map { .init(id: $0, reminder: .init(name: "Foo")) } } func allEntities() async throws -> [ReminderEntity] { ["foo", "bar", "baz"].map { ReminderEntity(id: $0, reminder: .init(name: $0)) } } } } @AppEntity(schema: .reminders.list) struct ListEntity: AppEntity, IndexedEntity { let id: String let myName: String var name: String { myName } // 3. Define how this entity is displayed to the user in shortcuts/Siri var displayRepresentation: DisplayRepresentation { DisplayRepresentation(title: "\(myName)") } @Property var type: MyListType // 4. Provide a query so the system can resolve specific lists static var defaultQuery = ListEntityQuery() }

We found an apparent iOS 27 WorkflowKit bug when implementing: @AppIntent(schema: .photos.editAsset) with an entity conforming to: @AppEntity(schema: .photos.asset) Despite Apple’s general guidance that schema entity types may be renamed, Siri only worked when our entity’s Swift type was named exactly AssetEntity. Controlled on-device results: AssetEntity — works PhotoAssetEntity — fails FooAssetEntity — fails For the failing names, neither the entity query nor perform() was reached. WorkflowKit logged: Failed to retrieve entity metadata Error Domain=WFActionErrorDomain Code=6 Siri responded: Unable to retrieve the data information to process. The generated App Intents metadata was internally consistent, and the issue persisted across clean installs and a device restart. Current workaround: name the .photos.asset entity type exactly AssetEntity. Tested with Xcode 27.0 beta (27A5252f) and iPadOS 27.0 (24A5423a). Filed with Apple as FB24604095 for anyone from Apple investigating this behavior.

I’m trying to understand the intended relationship between IndexedEntity.attributeSet, defaultAttributeSet, and displayRepresentation. For example: struct TrailEntity: IndexedEntity { var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "(trail.name)", subtitle: "(trail.location)" ) } var attributeSet: CSSearchableItemAttributeSet { let attributes = CSSearchableItemAttributeSet() attributes.keywords = trail.keywords return attributes } } Should attributeSet instead be initialized with defaultAttributeSet and then have the additional attributes assigned to it? var attributeSet: CSSearchableItemAttributeSet { let attributes = defaultAttributeSet attributes.keywords = trail.keywords return attributes } The documentation says defaultAttributeSet contains values derived from displayRepresentation, but it also describes precedence between displayRepresentation and attributeSet, which suggests Spotlight reads them separately during indexing. So what is the intended pattern? Does overriding attributeSet require including defaultAttributeSet to preserve title/subtitle/image metadata, or is attributeSet only meant for additional Core Spotlight metadata? If the latter, what is the intended use case for overriding or directly using defaultAttributeSet?

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?

I would like to understand the foundations of connecting my apps api structure to corporate reporting in regards to textile manufacturing. utilizing the core ML and vision through smartphone to link raw data capture and strategic execution.

Hi all, I’m seeing what looks like a bug with AppShortcutParameterPresentation and the Shortcuts app. Any time I provide an OptionsCollection to a shortcut so I can give it a nice category name and symbol in Shortcuts, it hides all other existing app shortcuts that my app has from the UI. I have created a sample that illustrates the problem. My app provides two App Shortcuts: A simple shortcut with no parameters. A shortcut with two parameters. Its Destination parameter uses AppShortcutParameterPresentation to generate “Home” and “Office” options in a separate section. When the second shortcut is present, the first parameterless shortcut disappears from the Shortcuts app. If I comment out the shortcut containing parameterPresentation, the parameterless shortcut appears again. Before commenting out: After commenting out the second shortcut: Here's the code: import AppIntents struct ParameterlessIntent: AppIntent { static let title: LocalizedStringResource = "Parameterless Intent" static let description = IntentDescription("Runs without asking for any parameters.") func perform() async throws -> some IntentResult { .result() } } struct ParameterizedIntent: AppIntent { static let title: LocalizedStringResource = "Parameterized Intent" static let description = IntentDescription("Runs with a destination and a copy count.") // The same provider is used by this parameter and by ParameterPresentation below. @Parameter( title: "Destination", optionsProvider: DestinationOptionsProvider() ) var destination: String @Parameter(title: "Copy Count", default: 1) var copyCount: Int static var parameterSummary: some ParameterSummary { Summary("Send \(\.$copyCount) copies to \(\.$destination)") } func perform() async throws -> some IntentResult { .result() } } nonisolated struct DestinationOptionsProvider: DynamicOptionsProvider { func results() async throws -> [String] { // Each generated App Shortcut option is a value for the Destination parameter. ["Home", "Office"] } } struct BugReproductionShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { // This parameterless shortcut should always appear in the Shortcuts app. AppShortcut( intent: ParameterlessIntent(), phrases: [ "Run the parameterless shortcut with \(.applicationName)" ], shortTitle: "Do I exist?", systemImageName: "1.circle" ) #warning("The presence of this shortcut causes the top one no longer appear in Shortcuts.app") AppShortcut( intent: ParameterizedIntent(), phrases: [ "Run the parameterized shortcut with \(.applicationName)" ], shortTitle: "Parameterized Shortcut", systemImageName: "2.circle", parameterPresentation: ParameterPresentation( for: \.$destination, summary: Summary("Send to \(\.$destination)") ) { // This title and symbol create a separate section in Shortcuts. OptionsCollection( DestinationOptionsProvider(), title: "Destination Shortcuts", systemImageName: "mappin.and.ellipse" ) } ) } } This code and reproduction is as of Xcode 27 Beta 6 and happens on older versions as well. Is there a known limitation with this or is this somehow expected behavior? If so, how can I mitigate this issue and provide a nice title for another shortcut, while keeping the old parameterless shortcuts present? Thanks!

I've looked and looked and can't seem to find anything obviously wrong, so I'll ask here. Are NSTableViewAppIntentsDataSource protocol methods expected to be called? Have others had success with this? I've got an extremely trivial NSViewController subclass that conforms to NSTableViewDataSource, NSTableViewDelegate, NSTableViewAppIntentsDataSource. Things I've verified: The NSTableView is setup in a storyboard and the delegate and data source are connected to the view controller. In viewDidLoad while attached to the debugger I see this works. The table view includes a single row and appears populated when running the app. There seems to be no way to assign the appIntentsDataSource view controller in the storyboard, so that's assigned in code in viewDidLoad for the view controller. I can confirm it's correctly set in the data source methods for the table view. I have an AppEntity conforming type and AppIntentsPackage conforming type in the project. I can look at the actionsdata in the built product to confirm the entity is registered. Here's the entirety of the view controller: class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate, NSTableViewAppIntentsDataSource { @IBOutlet var tableView: NSTableView! func numberOfRows(in tableView: NSTableView) -> Int { print("numberOfRows(in:)") return 1 } dynamic public func tableView(_ tableView: NSTableView, objectValueFor tableColumn: NSTableColumn?, row: Int) -> Any? { print("tableView(_:objectValueFor:row:)") return NSObject() } override func viewDidLoad() { super.viewDidLoad() tableView.appIntentsDataSource = self } override var representedObject: Any? { didSet { // Update the view, if already loaded. } } dynamic public func tableView(_ tableView: NSTableView, appEntityIdentifierFor row: Int) -> EntityIdentifier? { print("ViewController.tableView(_:appEntityIdentifierFor:)") return EntityIdentifier(for: MyFancyEntity.self, identifier: "1234") } } Unfortunately, while attached with a debugger, ViewController.tableView(_:appEntityIdentifierFor:) just never seems to be called.

Apple's 8 June 2026 announcement states that developers in the EU will not be able to test or use the new Siri AI features in their apps for iOS 27, iPadOS 27 or watchOS 27. I am an EU-based developer building apps for users in multiple markets. App Intents Testing, simulator checks and unit tests can validate parts of an implementation, but they do not appear to replace end-to-end validation of Siri AI behaviour on supported iPhone and iPad hardware. What is Apple's supported route for an EU-based developer to validate the following for users in supported markets? • intent discovery and invocation • parameter resolution and follow-up interaction • error handling and confirmation flows • Siri's presentation and completion of an action • behaviour on supported physical devices Is an official remote-device environment, controlled developer testing mode or another Apple-supported arrangement available or planned? I am not asking for a way to bypass regional restrictions. I am looking for documented, compliant testing guidance for developers serving a global App Store. I have filed Feedback Assistant report FB24276767 about this testing-access issue. Apple source: https://www.apple.com/newsroom/2026/06/due-to-dma-siri-ai-delayed-in-eu-for-ios-27-and-ipados-27/

App intent has a perform method that is async and can throw an error, but I can't find a way to actually await the result and catch the error if needed. If I convert this working but non-waiting, non-catching code: Button("Go", intent: MyIntent()) to this (so I can control awaiting and error handling): Button("Go") { Task { do { try await MyIntent().perform() // 👈 } catch { print(error) } } } It crashes: AppDependency with key "foo" of type Bar.Type was not initialized prior to access. Dependency values can only be accessed inside of the intent perform flow and within types conforming to _SupportsAppDependencies unless the value of the dependency is manually set prior to access. Although it is invalid since the first version is working like a charm and dependencies are registered in the @main App init method and it is in the perform flow. So how can we await the result of the AppIntent and handle the errors if needed in the app? Should I re-invent the Dependency mechanism?

As App Intents power multi-step workflows via Siri, Shortcuts, Spotlight, and Apple Intelligence, I would like to request a platform pre-action policy surface: Before intent perform(): input: intent_id, parameters, caller_agent_id, session_id, risk_hints output: allow | warn | deny | require_confirmation side: local audit_receipt Why this is needed Sandbox and TCC solve app isolation and one-time permission grants. Multi-step agentic loops introduce a different risk shape: Destructive tool selection from noisy natural language2. Uncapped retry / network loops3. Unauthorized data movement across app boundaries4. Financial / identity / Wallet actions that need dual control even when the app is already authorized Prompt-only or documentation-only guidance is not enforceable mid-loop. Apple-aligned properties On-device evaluation by default (privacy)- Complements TCC / sandbox â does not replace them- User-visible WARN / DENY with recoverable explanation- Optional Instruments-style â agent action timelineâ with gate verdicts Risk classes (map to entitlements mental model) | Class | Example | Default posture || --- | --- | --- || Read local | calendar, on-screen text | Allow / low friction || Cross-app write | paste into finance app | Warn or confirm || Destructive | delete, wipe, revoke | Deny or hard confirm || Network exfil | send sensitive context off-device | Deny until confirm || Financial / Wallet | transfer, mint pass | Always confirm | Related discussion There is already an excellent thread on pre-effectuation / execution finality for high-consequence App Intents. This request is complementary: a first-class, developer-visible pre-action hook (ALLOW / WARN / DENY / CONFIRM) at the intentâ action boundary, plus local audit receipts. Shipping reference (independent OSS control plane) I ship ThumbGate (npm thumbgate) â a local-first pre-action firewall used today for AI coding agents: PreToolUse / MCP interception, ALLOW/WARN/DENY, thumbs feedback â prevention rules. Public: https://thumbgate.ai · https://github.com/IgorGanapolsky/ThumbGate I will also file this as a Feedback Assistant Suggestion. Looking for: Confirmation this belongs under App Intents / Apple Intelligence2. Any existing API I missed for third-party or system-level pre-perform gates3. The right internal owner / Feedback area if this should go through a different channel Happy to share a one-pager with the risk taxonomy and proposed hook shape.

Apple's strict contracts for App schema domains are great if you have something which fits into that domain. There are endless options with AppSchema domains outside that of what apple have created. Does anyone know if apple will open the door to custom AppSchema domains? This would be a "game-changer". Is there any insight on what the future holds?

On watchOS, once the "Turn on [App] shortcuts with Siri?" prompt has been declined for an app, is there a user-facing way to turn it back on? On iOS I found the per-app Siri toggle, and re-enabling it restored voice invocation immediately. I cannot find any equivalent on watchOS, in the watch Shortcuts app, in watch Settings, or in the paired iPhone's Watch app. If one exists I would appreciate a pointer. If it does not, I would like to know whether that is expected. What I am seeing I have an iOS app with a companion watchOS app. Each declares its own AppShortcutsProvider and App Intent. Modern App Intents only, no SiriKit, no Intents extension. On one Apple Watch, saying the trigger phrase transcribes correctly on screen, then falls through to a generic Maps business search. The intent is never invoked. On that same watch the App Shortcut appears in the watch Shortcuts app and runs correctly when tapped, and Siri is otherwise healthy. The same phrase works on the paired iPhone. Why I believe the app is fine On a second iPhone and Apple Watch on a different Apple Account, the phrase spoken to the watch returned my intent's own dialog from perform(). Two control apps also behave correctly, including one with an iOS host plus embedded companion watch app matching my production structure, which prompted and worked on both devices. Reading Metadata.appintents/extract.actionsdata from the built watch app shows the provider registered and all phrase templates well formed. The state survives deleting the app. I deleted it from both devices, power cycled both, and reinstalled. The iPhone worked immediately without re-prompting. The watch continued to fail without prompting. Both retained their prior opt-in state. The app's bundle identifiers changed during a rename several months ago. I believe the prompt appeared on the watch then and was dismissed. Environment Apple Watch Ultra, watchOS 26.6. iPhone on iOS 18.6. Xcode 26.1.1. Deployment targets iOS 18.6 / watchOS 11.6. Companion watch app, WKRunsIndependentlyOfCompanionApp = NO. Already ruled out on device, each with a clean install and watch restart: CFBundleSpokenName, one word and spaced Watch PRODUCT_NAME / CFBundleName matched to the spoken app name Removing updateAppShortcutParameters() from the watch App.init() Adding the com.apple.developer.siri entitlement to the watch target Phrase collision between phone and watch providers, a watch-only phrase also failed Siri domain collision on the trigger words, a neutral phrase also failed Intent identifier collisions between the phone and watch bundles A brand new, uniquely named intent with canonical syntax and no gating was also ignored Questions Is there a user-facing setting on watchOS, or in the paired iPhone's Watch app, to re-enable App Shortcuts for a specific app after the prompt has been declined? If not, is there any supported recovery short of erasing the watch and setting it up as new? Restoring from backup appears to bring the state back. Is there any API for an app to detect that its App Shortcuts opt-in is off, so it can show guidance instead of a silently dead feature? INPreferences.siriAuthorizationStatus() is not a valid proxy, it reports authorized on the affected device. Happy to provide a sysdiagnose with the App Intents logging profile, or either control project.

Anyone able to get some neat SiriAI experiences working? Anything that makes you think “man I hope other developers do this in their apps too!”? (I’m willing!)

I'm trying to get some clarity on how the new Siri deals with IndexedEntities and whether it's worth adopting, considering our app does not fit into any of the predefined domain schemas. In running some tests with the TravelTracking sample app, it seems the only way I can get Siri to show any of the referenced entities is by using the exact phrasing (or extremely close to it) in one of the donated shortcuts. If I ask Siri to "Find closest landmark in TravelTracking" produces a result from the App in the form of an app snippet. But, if I then ask it "Text the description to Jane", it seeds the text with something like, "Niagara Falls is located in North America", instead of what's in the description field of the entity. General questions about the indexed data fail to show any results at all in Siri. For example: "Show me some landmarks from TravelTracking" or "Find Mount Fuji in TravelTracking" produce no results, even though the landmarks are indexed. My original assumption was that indexing data from your app would make it available to Siri, but it only seems to show up in on-device search and not in conversation with Siri itself. So is it the case that such data is only available through a Siri conversation if either you can adopt a domain schema or create a shortcut and use very close to the exact phraseology? And in the case of the latter, you can't really act on the returned entities because basically all you get is what is shown in a snippet? Maybe the on-screen intelligence picks up something here (seems to), but nothing deeper, even if it is defined in the entity. I've put in a feedback request (FB23796681) for a general database domain with schema for common database operations. Perhaps something like this and way to describe record types to aid in understanding from the LLM would go a long way toward making Siri more flexible for agentic use? I can get Siri to do a lot of the things that were shown at WWDC, but that tends to make you think you can do similar things with other types of apps and when you can't because of the domain limitations, it's very frustrating and feels limiting. It seems the domain types fit the apps Apple ships with the OS (Mail, Photos, Notes, etc), but not other types of apps that don't fit that criteria. If I'm missing something here, any guidance would be appreciated.

We're implementing the App Intents Phone schema domain in our app to enable Siri to initiate calls to our contact entities via our voip. We've implemented a .phone.startCall intent and registered our entities as .phone.phonePerson. The intent provides both the required destination and audioVisualMode parameters, and the perform() method is implemented to handle the call. However, the perform() method is never invoked. Instead, Siri either: Says that the phone number is not linked, or Announces that it is calling, but our app intent is never executed. Anybody implemented this Phone schema domain and it s working successfully ? Sample Code: struct StartCallIntent: AudioRecordingIntent, AudioPlaybackIntent { var destination: CallDestination var audioVisualMode: CallAVMode init(contact: ContactEntity, mode: CallAVMode = .audio) { self.destination = .phonePerson(contact) self.audioVisualMode = mode } func perform() async throws -> some IntentResult { print("Call Initiating to contact") return .result() } @AppEnum(schema: .phone.audioVisualMode) enum CallAVMode: String, CaseIterable { case audio case video } @UnionValue enum CallDestination: Sendable { case phonePerson(ContactEntity) case group([ContactEntity]) } @AppEntity(schema: .phone.phonePerson) struct ContactEntity: IndexedEntity { static var defaultQuery = ContactEntityQuery() let id: UUID var person: IntentPerson }

We have an app that supports iOS 18+ We have a couple of AppEntity(s) that we are keen to make work with the new schemas along with several AppIntent(s). We cannot increase our floor to iOS 27 for obvious reasons. All the documentation suggests using the macros, e.g. @AppEntity(schema: .audio.song) struct SongEntity { ... } This refuses to compile below iOS 26. It's possible to add availability checks, e.g. @available(anyAppleOS 27, *) @AppEntity(schema: .audio.song) struct SongEntity { ... } But then the whole entity becomes unavailable on pre-27 OSes. So I tried moving the macro onto an extension, e.g. struct SongEntity { ... } @available(anyAppleOS 27, *) @AppEntity(schema: .audio.song) extension SongEntity { ... } But this results in a compiler error: 'extension' macro cannot be attached to extension (extension of 'SongEntity') One other option is to create a new entity with a totally different name and mark it as isAssistantOnly but this has a lot of quite negative downstream effects that make it unworkable. For example: a lot of code duplication duplication in search indexes if we index both sets of entities awkwardness trying to use NSUserActivity when we have 2 different entity types pain in downstream AppIntent arguments which would require duplicating every AppIntent which has more cascading effects The same issues are present in AppIntent schemas too where even trying to add the most basic @AppIntent(schema: .system.open) to our existing OpenIntent doesn't seem possible for all the same reasons. I am really struggling with how to structure code so we can support schemas, currently I don't really see a path forward here until our floor raises to iOS 27. Is there a way to make this work nicely with the current APIs? What are others doing here? How can apps can ship in September and support both this and pre iOS 27 cleanly? Thinking about solutions here, my ideal would be that the macros are improved to either: be able to be applied to an extension rather than the structure itself. expand in such a way that they still build the core AppEntity / AppIntent on pre 27 OSes but then add the iOS 27 schema additions behind @available internally so they can be used with older targets as essentially no-ops on the current definitions.