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

Hello, I'm developing an iPhone alarm app with AlarmKit. The alert's secondary "Snooze" button uses secondaryButtonBehavior: .custom. Its secondaryIntent is a LiveActivityIntent with supportedModes: .background and authenticationPolicy: .alwaysAllowed. In perform(), the app saves an in-progress record, schedules a new fixed alarm with AlarmManager.shared.schedule(id:configuration:), cancels the original alarm only after scheduling succeeds, and then saves completion. If something fails partway, the original alarm may remain, with or without the newly scheduled one. Simplified configuration (not a standalone sample): let presentation = AlarmPresentation( alert: AlarmPresentation.Alert( title: "Alarm", secondaryButton: AlarmButton( text: "Snooze", textColor: .white, systemImageName: "repeat"), secondaryButtonBehavior: .custom)) let attributes = AlarmAttributes<ExampleMetadata>( presentation: presentation, tintColor: .indigo) let configuration = AlarmManager.AlarmConfiguration( schedule: .fixed(fireDate), attributes: attributes, stopIntent: StopIntent(id: alarmID), secondaryIntent: SnoozeIntent(id: alarmID), sound: .named(soundName)) What we observed We deliberately injected an app-side error inside the intent, using two different test apps on a spare iPad: Observations 1 and 2: a small standalone AlarmKit probe app (iPadOS 26.2.1, default alarm sound). It does not use our app's core logic. Observation 3: a separate validation app that uses our app's core logic (iPadOS 26.7, bundled alarm sound). Each condition was observed only once, so these are not reproducible causal claims. Error before scheduling the new alarm (probe app, device locked): The original alarm kept sounding, and snooze could be tapped again. We recorded several intent entries after the first error, but we can't tell which were user taps and which were system redeliveries. The alarm read as .alerting until the system Stop control was used. Error after the new alarm was scheduled successfully (probe app): The original kept sounding for about 15 seconds until system Stop. The new alarm remained and fired at its scheduled time about three minutes later. Error before scheduling (validation app, device unlocked with the app in the foreground): The alert appeared as a compact banner. After the failed snooze, the app was terminated and relaunched as part of the test procedure, and a test-only control allowed one retry. After that, the banner controls were no longer available, and reads over the next few minutes still reported the original as .alerting. About two hours later, cancelling it with the app's OFF action succeeded. We can't separate the effects of the intent failure, foreground presentation, relaunch, and test-only retry. About hardware buttons: I understand from the AlarmKit FAQ that a physical button stops the currently alerting alarm and that stopIntent is called on dismissal. In observation 3, a volume button was pressed after the banner controls were gone, and audio was no longer heard. Our logs did not capture a stop-intent execution, though that doesn't prove it wasn't invoked. I'm not asking about the general hardware-button behavior. My question is only whether that guidance also applies to an alarm in the state left by a failed custom intent (question 3 below). Questions When a custom secondary LiveActivityIntent.perform() throws, what behavior should an app expect for the original alarm's state and alert presentation? Are there documented limitations or differences between the locked and foreground (banner) presentations? What's the recommended way to report an unsuccessful snooze? Should the intent propagate the error, or catch it and return .result() while tracking the failure in the app? If the original stays .alerting, is invoking the same secondary intent again for the same alarm ID supported, and what concurrency or redelivery assumptions should the app avoid? If an alarm reads as .alerting but has no visible controls or audio after such a failure, which public APIs or user actions are recommended for recovery? Does the FAQ's physical-button and stopIntent guidance still apply in that state? How should an app choose among stop(id:), cancel(id:), or a new schedule without cancelling a valid future alarm? I've read the AlarmKit documentation and the AlarmKit FAQ (https://developer.apple.com/forums/thread/797158), but couldn't find guidance on this failure case. Any advice is appreciated. Thank you!

Hello, I'm developing an iPhone alarm app with AlarmKit. The alert has a custom secondary button whose intent conforms to LiveActivityIntent, declares supportedModes: .background and authenticationPolicy: .alwaysAllowed, and passes an alarm ID to app code from a @MainActor perform() implementation. The intent lives in the app target. It is not shared with a widget or an App Intents extension. The operation persists an in-progress record, awaits scheduling a new alarm, cancels the original only after scheduling succeeds, and then persists completion. After an interruption or relaunch, recovery reads the persisted original and candidate IDs and checks the system's alarm inventory. I want to understand which execution guarantees the app can rely on, so that recovery never schedules a duplicate alarm or cancels a valid candidate. I've read the LiveActivityIntent and App Intents runtime documentation. I understand how execution placement and foreground/background modes are described, but I couldn't find a public guarantee about overlap or redelivery when the app process is replaced. To be clear, I have not observed two simultaneous processes or duplicate execution in this setup. This is a question about what the app may assume, not a bug report. Questions For this app-target LiveActivityIntent configuration on iOS/iPadOS 26.x, can an older process of the same app still be executing an alarm-button intent while a newly launched process begins another invocation? Is there a documented single-process or handover guarantee an app may rely on? I'd appreciate it if the answer could distinguish multiple concurrent invocations within one process from overlap between an old and a newly launched process. Can the same alarm-button action be redelivered after an interruption or relaunch, including after perform() has thrown or returned? Which serialization or at-most-once guarantees, if any, apply to invocations for the same alarm ID, and which duplicate-delivery defenses must the app provide? I'm not assuming that every invocation comes from a new user tap. If the process that issued an AlarmKit scheduling or cancellation request terminates, may the app assume that the request has either completed or been abandoned before a newly launched process calls AlarmKit? If not, which public API checks or sequencing are recommended before recovery modifies the original or candidate alarm? I'm looking for supported app-level assumptions and recommended safeguards, not internal process lifecycle details. The app must preserve valid alarms and must never report an uncertain result as success. The shipping target is iPhone, with a minimum deployment target of 26.1. Earlier isolated testing on an iPad (9th generation, including iPadOS 26.7) did not show the overlap described above. Related question about the alert presentation after an intent error: [https://developer.apple.com/forums/thread/849075] Thank you!

Since I updated to this os 27 in my iPhone 16 plus the siri ai and Apple Intelligence is got freeze in “ Adding support for Siri is in progress. Siri will be unavailable until the update is complete. “ I updated on 21/09/2026 today date is 30/09/2026 I tried all troubleshooting methods and watch a bunch of YouTube videos, but still stuck in the same position. I contacted Apple support. But , they also do nothing. Please anyone help me to how to get siri ai beta @appleindia @applesupport

I’m working on an app that deals with a list of text items, so I started with the document app template in Xcode. I have the app basically doing what I want it to do, but I want to be a good ecosystem citizen, so I’d like to conform to app intents. I think that app intents will able to do what I want - accepting text and passing it back out - but I can’t figure out how to access the document outside of my content view and associated subviews. Any guidance would be appreciated. Thank you, Don Carlile

I want to share a Siri / Apple Intelligence issue I have been troubleshooting since the iOS 27 beta cycle, together with the configuration that finally resolved it. The issue started during iOS 27 beta, continued across multiple beta builds, and was still present after I updated to the official iOS 27 release. Updating iOS alone never fixed it. The main problem was that Siri / Apple Intelligence repeatedly failed to complete activation. Settings would remain stuck on: “Adding support for Siri is in progress” The Siri app would sometimes show: “Siri is not available” Siri also frequently fell back to the older floating-sphere interface instead of using the newer glowing-edge interface. Sometimes the new Siri interface would suddenly appear and work normally, but later it would fall back again. The most repeatable symptom involved charging. When the iPhone was connected to power, Siri sometimes appeared to finish downloading and would temporarily work normally. After disconnecting the charger, Siri could become unavailable again or the system would behave as though Siri resources still needed to be downloaded. Connected to power → Siri sometimes worked normally Disconnected from power → Siri could return to downloading / unavailable There was also a difference between Wi-Fi and cellular data. On cellular data, iOS sometimes said Wi-Fi was required to continue downloading Siri resources. After connecting to Wi-Fi, it would return to “Adding support for Siri is in progress” and still fail to finish. Apple Intelligence storage also behaved abnormally. At one point, iPhone Storage showed approximately 7.37 GB in use. Later, the Apple Intelligence entry disappeared and storage usage decreased, then reappeared after changing language settings. Before finding the working configuration, I had already tried restarting, Reset All Settings, Recovery Mode update, multiple iOS 27 beta builds, the official iOS 27 release, different Wi-Fi networks, cellular data, disabling VPN/proxy, changing languages, removing additional languages, switching between old and new Siri, and leaving the phone on Wi-Fi and power for long periods. None provided a permanent fix. After repeated testing, the issue appeared to involve network transport, routing consistency, Siri language / voice configuration, Siri AI authorization, and local asset refresh. My final working setup was: System language: English (United States) Region: United States Siri language: English (United States) Siri voice: American Apple Intelligence enabled Proxy environment: Shadowrocket Proxy transport My proxy node uses an AnyTLS-based configuration. Previously, UDP traffic was enabled. During troubleshooting, some Apple / iCloud requests appeared unreliable when using UDP / QUIC through this node, with timeouts, resets, or repeated retries. I changed the node transport to TCP only while keeping TLS enabled: TCP + TLS After this change, Apple-related authentication and asset requests appeared much more stable. Routing rules This was one of the most important changes. I use split tunneling so that Chinese apps can remain DIRECT while selected traffic uses the proxy. However, some Apple traffic was being matched by broader fallback rules such as: apple.com,DIRECT GEOIP,CN,DIRECT This meant some Siri / iCloud / Apple Intelligence requests could use the proxy while related requests went directly through the local connection. I added these high-priority rules and moved them above broader Apple / DIRECT / GEOIP rules: DOMAIN-KEYWORD,gateway,PROXY DOMAIN-KEYWORD,probe,PROXY DOMAIN-KEYWORD,gdmf,PROXY DOMAIN-KEYWORD,guzzoni,PROXY DOMAIN-SUFFIX,iphone-ld.apple.com,PROXY Rule priority was important. If broader DIRECT rules were above these entries, the specific traffic could still bypass the proxy. After moving these rules to the top, the relevant Apple traffic consistently followed the same network path. Split tunneling still worked normally, and apps such as WeChat, Alipay, Meituan, and Xiaohongshu could remain DIRECT. Language and Siri configuration I standardized the Siri environment: System Language: English (United States) Region: United States Siri Language: English (United States) Siri Voice: American I selected an American Siri voice, such as Voice 4. After changing everything to the same English (US) environment, asset loading became more consistent. Enable Siri AI I manually selected: Try Siri AI (Beta) and completed the authorization process. I also temporarily disabled “Require Face ID” for the standalone Siri app while troubleshooting. I cannot confirm that this directly affected the download, but it removed an extra authentication layer while testing. Refresh local language assets I opened Apple’s built-in Translate app, deleted the downloaded English (US) language package, and downloaded it again. My goal was to refresh the local language / MobileAsset download state. I cannot confirm that Translate directly controls Siri’s generative models, but this appeared to help clear the remaining stuck asset state. Final installation step After making all of the above changes, I connected the iPhone to Wi-Fi and power, locked the screen, and left the device idle for approximately 10–15 minutes. After this, the Siri / Apple Intelligence state finally changed and remained stable. Current result: Siri consistently uses the full-screen glowing-edge interface Type to Siri works correctly Siri no longer falls back to the legacy floating-sphere interface “Siri is not available” no longer appears “Adding support for Siri is in progress” is no longer permanently stuck Apple Intelligence remains active Siri continues working after disconnecting the charger Split tunneling still works normally Most importantly, the previous charging-related behavior is gone. Before: Connected to power → Siri temporarily worked Disconnected from power → Siri failed again Now: Siri continues to work normally whether or not the device is connected to power. I am not claiming that Apple has officially documented every domain or internal process above as the root cause. These findings are based on repeated troubleshooting and network behavior observed on my own device. However, this issue persisted from the iOS 27 beta cycle through the official iOS 27 release, and standard system updates alone did not resolve it. In my case, the successful fix only came after correcting the combination of: TCP transport + consistent Apple routing + English (US) system / Siri configuration + Siri AI authorization + local asset refresh. If anyone else is experiencing “Adding support for Siri is in progress,” “Siri is not available,” repeated fallback to the legacy Siri UI, Apple Intelligence storage disappearing / reappearing, or Siri working while charging but failing after unplugging, I would be interested to know whether the same configuration also resolves the issue on other devices.

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?

Since iOS 18, I have an OpenIntent to open documents. For Siri AI, I understood that I need to annotate the entity with @AppIntent(schema: .system.open) for Siri AI to be able to open documents. This is only supported starting with iOS 27. I tried duplicating the intent (one for iOS 27, one for the other versions), however, Xcode complains and says that only one OpenIntent is possible per target entity. How are we supposed to: support Siri AI "open" functionality preserve functionality for older iOS versions ? Thank you

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

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 building a cross-platform app (.NET MAUI) on ios with a feature that lets users send a block of text to their preferred note-taking app to save for later. This works fine via their documented x-callback-url schemes (e.g. bear://x-callback-url/create?text=...). I'd like to support Apple's own Notes app the same way, but I can't find a documented mechanism to do so. Questions: Is there a URL scheme for Notes.app that a third-party app can use to open it, and if so, does it support passing in content for a new note? Is there any officially supported way — App Intents, or otherwise — to create a new note with pre-filled text in Notes.app from another app? Does the new Notes domain under App Intents (iOS 18+) apply to Apple's own Notes app, or is it purely a schema that third-party note apps can adopt for themselves? If it does apply, is there a way to invoke it directly from another app's UI rather than only via Siri/Shortcuts? If none of the above exists, is routing through the standard share sheet the intended/only supported approach for this use case going forward? Thanks in advance — wanting to make sure I'm not missing a documented mechanism before concluding this isn't possible.

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() }

Hello, I have a question about App Intents and the Action button on iPhone. I have an App Intent that opens the app and navigates to a specific entity, conforming to OpenIntent with a single AppEntity parameter. The entity conforms to EnumerableEntityQuery, and the intent is registered as an App Shortcut via the AppShortcutsProvider. When assigning this shortcut to the Action button in Settings, the system doesn’t prompt the user to select a default entity upfront. Instead, it prompts on every activation, creating friction. In contrast, shortcuts like “Open Note…” and other third-party ones prompt the user for a note to open when setting up the Action button, and its title also includes three dots, indicating a pre-configurable parameter. My shortcut’s title shows no dots. What’s required to make an App Shortcut prompt for a default parameter during Action button setup? Sincerely, Holger

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?

Context I built an app entirely using Swift Playgrounds on iPad (no access to a Mac / Xcode). The app is distributed via TestFlight and installed on an iPhone. Problem I implemented an AppShortcutsProvider with simple AppShortcut entries (code below), but no shortcuts show up in the Shortcuts app, in the list of apps with shortcuts, or via Siri. What I've already tried without success: Full restart of the iPhone Deleting the app's data Fully uninstalling and reinstalling the app A new TestFlight build (with incremented build number) after adding the code Confirming the phrases correctly include (.applicationName) as required Question Is the Extract AppIntentsMetadata build step (which generates the metadata.appintents file) actually executed when compiling/submitting via Swift Playgrounds on iPad, or is this a known limitation of the tool that would prevent App Shortcuts from being indexed by Shortcuts/Siri? Environment Swift Playgrounds version: [check in the app under Settings > General > About] iOS version on test iPhone: [fill in] Project deployment target: [fill in if known, otherwise note that you have no way to check this without Xcode] Provider code: import SwiftUI import AppIntents // ============================================================ // MARK: - TEST INTENT // ============================================================ struct TestExpenseIntent: AppIntent { static let title: LocalizedStringResource = "Test dépense" static let description = IntentDescription( "Teste l'intégration de l'application avec Raccourcis." ) static let isDiscoverable = true func perform() async throws -> some IntentResult { return .result(dialog: "Ça fonctionne !") } } // ============================================================ // MARK: - ADD EXPENSE INTENT // ============================================================ struct AddApplePayExpenseIntent: AppIntent { static let title: LocalizedStringResource = "Ajouter une dépense" static let description = IntentDescription( "Ajoute une dépense à un Tricount." ) static let isDiscoverable = true static let openAppWhenRun = false @Parameter(title: "Montant") var amount: Double? @Parameter(title: "Marchand") var merchant: String? func perform() async throws -> some IntentResult { let valAmount = amount ?? 0.0 let valMerchant = merchant ?? "Inconnu" print("Montant :", valAmount) print("Marchand :", valMerchant) return .result( dialog: "Dépense de \(valAmount) € chez \(valMerchant)." ) } } // ============================================================ // MARK: - SHORTCUTS // ============================================================ struct MyAppShortcuts: AppShortcutsProvider { static var shortcutTileColor: ShortcutTileColor = .blue static let appShortcuts: [AppShortcut] = [ AppShortcut( intent: TestExpenseIntent(), phrases: [ "Tester \(.applicationName)" ], shortTitle: "Test dépense", systemImageName: "plus.circle" ), AppShortcut( intent: AddApplePayExpenseIntent(), phrases: [ "Ajouter une dépense dans \(.applicationName)", "Ajouter \(\.$amount) dans \(.applicationName)" ], shortTitle: "Ajouter une dépense", systemImageName: "plus.circle" ) ] }

When trying to access new Siri in macOS 27 beta 7 it always showing 'I’m having trouble with the connection. Please try again later.'. Tried changing the language multiple times and restarted the mac as well. But nothing resolved the issue. Has anybody faced this issue. is this related to network settings ?.

How do I disable the "Ask Siri" button in the SwiftUl context menu in macOS?