Hello, My understanding is that @Property(visibility: .internal) makes an AppEntity field available to the app and its extensions through App Intents while hiding it from Siri and Shortcuts. But both the app and its extensions can already read a plain Swift property on a CatEntity instance they’ve loaded. // Plain Swift property var internalNote: String // Internal App Intents property @Property(visibility: .internal) var internalNote: StringWhat does the annotation enable in practice that a plain Swift property doesn’t?

With the Siri AI Developer Preview in iOS 27.3 beta 1, we are exposing custom intents to Siri as tools with @AppIntent(.tool). Some of these only make sense for Siri, for example a read-only status tool whose result Siri phrases as an answer, or variants that would duplicate existing Shortcuts actions. Our app already has a long list of Shortcuts actions, so we would like these tools to be available to Siri AI without appearing as actions in the Shortcuts app. @available(iOS 27.3, *) @AppIntent(.tool) struct GetStatusIntent: AppIntent { static let title: LocalizedStringResource = "Get Status" @Parameter(title: "Item") var item: ItemEntity func perform() async throws -> some IntentResult & ReturnsValue<StatusEntity> { // ... } }What we have tried on iOS 27.3 beta 1: static let isDiscoverable = false hides the action from Shortcuts, but Siri then never called the tool and used a different one instead. Conforming to DeprecatedAppIntent while keeping it discoverable also hides the action, but Siri stopped calling the tool over repeated attempts. Removing the deprecation brought it straight back. isAssistantOnly would describe what we want, but it only exists on AssistantSchemaIntent, and combining .tool with a Siri-supported schema is a build error. ToolIntent itself has no requirements in the 27.3 SDK. IntentVisibility only applies to entity properties, and .internal hides the property from Siri as well. Questions: Is there a supported way to make an intent available to Siri AI while keeping it out of the Shortcuts action list? Is it intended that isDiscoverable = false and DeprecatedAppIntent also make a tool unavailable to Siri AI? If there is no such option today, is one planned, and is there a feedback number we should reference? Related question about schema intents: https://developer.apple.com/forums/thread/838658 Thanks!

Hello, Our app provides two actions in the Shortcuts app. However, on some devices running iOS 27, neither action appears, preventing users from setting up automations during onboarding. We have not observed this issue on earlier iOS versions. Implementation Both actions conform to LiveActivityIntent, with their corresponding App Shortcuts declared in an AppShortcutsProvider. Both have a required AppEntity parameter, with initial parameter options provided by EntityQuery.suggestedEntities(). We call updateAppShortcutParameters() at app startup and after saving changes to the platform selection. Observed behavior Only some iOS 27 devices are affected. Some affected users report that the actions appear a few days later, but we have not identified what triggers their appearance. Has anyone encountered similar behavior? Is there a known registration or indexing issue, or anything in this implementation that we should investigate? This blocks a key step in our new-user onboarding, so we would greatly appreciate any guidance or workaround. Thank you.

I'm building a voice app called Moonstone that works like a hands free coding agent for the iPhone. You talk to it and it opens apps, taps through them and gets real tasks done, mostly on a local model running on the phone. I have the side button access entitlement, an App Intent using the assistant activate schema, and my development profile installed on an iPhone 18 Pro Max on the iOS 27.2 developer beta. The docs say the profile is enough to test during development, but here in the US the Side Button option never shows up in Settings. I tried switching the region to Japan and restarting and it still didn't appear. I filed FB25304176. Has anyone outside Japan gotten the setting to show up on a development device?

Hello 👋, We finally gets our hands-on Siri AI here in France on macOS 27.2 As a macOS developer supporting App Intents into my app I would like to add App Schema to my AppIntent / AppEntity to make them available through Siri AI in my next release. So I've started by downloading the CometCal app and add a target for macOS (because I supposed the existing Mac Catalyst target provided was not supported by Siri AI ?). On my machine CometCal does not work with Siri AI. It either fail or repond it cannot do the action. Doing those actions (Find event, Create event, ...) in Apple Shortcut works just fine. Do I miss something specific on macOS ? A specific configuration or something ? Is Siri AI supposed to work on macOS as I tried to ? (I also tried making a Release build or moving the app into /Applications) NB: I don't have a Siri AI compatible iPhone (+ blocked in Europe) to run CometCal on iOS to compare with. Thanks,

Hi — I built SiriReady Bench, an external benchmark that measures whether an app's App Intents implementation is actually reachable the way people talk: static audit (App Schemas, IndexedEntity, View Annotations), a bilingual EN/JA utterance dataset (1,272 cases), and a real-run harness that drives built apps through AppIntentsTesting on an iOS 27.0 simulator (Xcode 27.1 / iOS 27.1 SDK). Repo: https://github.com/NagaYu/siriready-bench Dataset (dev split): https://huggingface.co/datasets/NagaYu/siriready-bench Four reference apps (messages/calendar, correct and intentionally broken versions) were measured. Every number is labelled by source (real / mock / static). Utterance-to-intent arrival is a rule-based mock — AppIntentsTesting calls intents directly and never exercises Siri's language understanding, and I say so in the results. A few measured findings I'd like to sanity-check with the team: Correct apps over-confirm. Even after a request names exactly one entity, perform() still requests confirmation (56 cases in messages, 54 in calendar, in the reference implementations). Is "always confirm" the expected behaviour for these schemas, or is there a supported way for the system to skip confirmation when resolution is unambiguous? No tolerance for typos or sound-alike spellings, and index gaps. spotlightQuery and entity string queries return nothing for misspelled or near-sound names. Possessive titles ("Jon's …"), conversation readings (Japanese yomi), and calendar aliases fall out of the index entirely — a Japanese calendar alias was not found and the event was created in the default calendar instead; designating a conversation by its reading returned 3 of 12 probes. Are readings/aliases intended to be indexed, and is fuzzy matching on the roadmap? The toolchain sets a floor. A messages app built without an entity string query does not compile: Xcode 27.1 raises a halting error requiring an EntityStringQuery, so in real runs that "broken" app scored higher than a static reading suggests. Sharing this because it changes what "broken" can even mean for App Intents in iOS 27. Privacy routing is input-dependent. In the broken calendar app, an off-device call was observed in 24 of 24 location-bearing requests and in none of the other 84 (intercepted locally, never sent). A static privacy finding alone doesn't tell you when it fires. Scores for the four apps (MOCK + REAL, real 54% · mock 25% · static 21%): messages_ok 95.0, messages_broken 68.8, calendar_ok 94.0, calendar_broken 83.4. Full tables, measurement conditions and the mock-vs-real divergence log are in BENCHMARKS.md in the repo. Physical-device Siri spot checks are protocol-only so far (not yet recorded) — also stated in the repo. I'd genuinely like to know which of these behaviours are known/expected, and whether the team would read a Feedback report on the indexing gaps. The project is available for transfer or licensing; contact is via my portfolio (linked in the repo README). — Yuta Nagao

I need a supported way for Dutch Siri to invoke Elegant Cook's built-in grocery actions directly, without requiring users to create personal shortcuts. The installed TestFlight version is 1.5.3 (32), on an iPad Air (5th generation). The owner reports iPadOS 26.6.1; the diagnostic archive identifies build 23G83. Siri is Dutch, with nl_BE runtime assets. Use with Siri is enabled and spoken responses are preferred. The main app uses App Intents and AppShortcutsProvider with three actions: add a grocery, read the list, and check off a grocery. The voice actions use scalar String parameters with requestValueDialog and return ProvidesDialog results. The phrases use the applicationName token and have packaged English and Dutch localizations. We do not register Notes or Home intents. Observed behavior: “Hé Siri, voeg boodschappen toe in Elegant Cook” and “Hé Siri, lees mijn boodschappenlijst in Elegant Cook” ask whether to use Elegant Cook or Notes. After selecting Elegant Cook, adding and reading work by voice. “Hé Siri, vink een boodschap af in Elegant Cook” and the registered app-name-first equivalent “Hé Siri, Elegant Cook boodschappen afvinken” instead produce the instruction to download Apple's Home app to use Intercom. “Hé Siri, open Elegant Cook” opens the installed app correctly. The signed build contains extracted App Intents metadata, compiled Dutch/English nlu.appintents assets and successful phrase-training output. These build checks do not establish successful device routing or App Shortcuts Preview validation. For one captured check-off invocation, local diagnostic analysis identified this sequence: the recognized utterance includes the correct app name; App Shortcuts are enabled; the intended CheckElegantCookGrocery action is a Siri candidate; app disambiguation then fails and explicitly redirects to Home/Intercom before the grocery operation. This trace covers check-off only. It does not prove that the add/read chooser has the same cause, or establish a definitive Apple framework bug. The private bug report is FB25058524. It includes selected evidence and source code. A full sysdiagnose has not been uploaded, and the isolated Swift example is not a compiled or validated reproducing Xcode project. We develop on Windows and use EAS cloud builds, so local Xcode App Shortcuts Preview is unavailable. The code-level support form currently directs us to this forum when we cannot provide a test project demonstrating the issue. Could an App Intents/DTS engineer advise: Which supported registration or metadata correction should we check when Siri identifies an explicitly named App Shortcut but chooses another domain before perform()? What targeted diagnostic evidence can distinguish an app configuration problem from a Siri routing defect without local App Shortcuts Preview? Is there a supported workaround for direct Dutch voice invocation on this OS build, without personal shortcuts or private system settings? We can prepare an isolated native sample project if required, but will clearly distinguish source preparation, cloud compilation and actual device reproduction. We do not want to claim a reproduction that has not been verified.

I'm investigating a Siri invocation failure with an explicitly declared App Shortcut phrase. The same underlying App Intent works when run directly in Shortcuts and when invoked by the name of a saved personal shortcut. Environment: iPhone 17 Pro Max, iOS 27.2 beta (24B5099f), clean restore without a backup. iPhone and Siri languages: Italian. Standard Siri, no Siri AI. Xcode 27.2 (27B5028f), iphoneos 27.2 SDK. Italian App Shortcut phrase and app metadata. PetroCheck 1.3 (637), already open during the failing invocation. The published phrase is “Trova carburanti vicini con PetroCheck”, declared using \(.applicationName). This is a phrase-based App Shortcut; the intent does not adopt an App Schema. What I observe: Saying the App Shortcut phrase produces a generic Siri error: “mi dispiace, ma si è verificato un errore”. Running the action directly in Shortcuts succeeds and records execution in the app's intent journal. Saving a personal shortcut named “Diagnostica Petro” with just that action, then saying “Esegui Diagnostica Petro”, also succeeds and records execution. Returning only a minimal Text snippet from the original intent does not resolve the phrase invocation failure. For two captured failing phrase invocations, the device logs show BackgroundShortcutRunner failing to resolve the workflow reference: -[WFWorkflowDatabaseRunDescriptor(Conversion) workflowReferenceWithDatabase:error:] Couldn't find shortcut with descriptor: <private> reason: unable to resolve workflow reference from descriptor The first of these attempts has no new entry at the recorded start of perform(). The descriptor itself is redacted, so I cannot identify which reference Siri selected. A subsequent attempt also contains these assistantd messages shortly before the descriptor error: Found no AppShortcutTargets! Could not cast to VoiceCommand task to create AppShortcut invocation AppShortcuts enablement result=false I am including these as observations, without interpreting them as proof of a disabled setting. Calling updateAppShortcutParameters() at launch did not resolve the failure. I checked the compiled device bundle's App Intents metadata: the action is discoverable, its fuel parameter is optional, and the declared shortcut points to the correct intent. The Italian training metadata contains the phrase and the application name PetroCheck. This verifies the compiled metadata, not the device's registration database. I then built a separate app, “Prova Petro”, with a different bundle identifier, a fresh phrase, one intent with no parameters, and a dialog-only result. It has no location, networking, snippet or dependencies from the original app. The Siri phrase fails in this app too. I have not yet captured its intent diary or host logs, so I cannot claim that the minimal app fails at exactly the same stage. These are the core declarations from the compiled minimal project; the sample's journal calls are omitted here: import AppIntents struct RoutingProbeIntent: AppIntent { static let title: LocalizedStringResource = "Verifica collegamento Siri" static let supportedModes: IntentModes = [.background] func perform() async throws -> some IntentResult & ProvidesDialog { return .result(dialog: "Il comando Siri ha raggiunto Prova Petro.") } } struct ProbeShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: RoutingProbeIntent(), phrases: ["Verifica Siri con \(.applicationName)"], shortTitle: "Verifica collegamento Siri", systemImageName: "checkmark.circle" ) } } The minimal app's display name is Prova Petro, and the spoken phrase is “Verifica Siri con Prova Petro”. Its App.init() calls ProbeShortcuts.updateAppShortcutParameters(). The extracted metadata confirms one shortcut, zero parameters, dialog-only output, and the Italian application name and phrase. Has anyone reproduced this difference between an App Shortcut phrase and a named personal shortcut on iOS 27.2 beta, particularly with Italian phrases? Feedback Assistant: FB25077916. The complete minimal Xcode project and scoped diagnostics are attached to the report. Is there anything missing from this setup, or a supported way to diagnose the unresolved shortcut reference? Comparisons with other OS builds, languages or devices would be useful. I have not yet established a regression against a stable OS release. Prova Petro minimal source and Siri routing logs

I had a complete voice-only experience working with AppIntents and AppShortcuts on iOS 27.0 prior to enabling Siri AI. Once I enabled Siri AI, Siri refused to recognize any of the donated phrases in one particular AppShortcut. It still worked for several others. For the AppShortcut that no longer works, Siri responds to some of the phrases claiming the app doesn't support that action through Siri, and Siri responds to some of the phrases telling me I need to open the app to do that. FB24854409 includes a Sysdiagnose file. Note that I'm aware of App Schemas, but none apply well to my app.

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

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?

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