Hi, We're building a voice assistant app. The user speaks to the assistant through a Bluetooth earset; the app records the speech, transcribes it and the assistant acts on it. We want the user to start and stop that capture from the earset button while the iPhone stays locked, without the Phone call UI. We prototyped this with the PushToTalk framework and have two questions. 1. Headset play button does not reach our joined PTT channel Setup (minimal test app, nothing else running): iPhone 14 Pro Max, iOS 26.6.1 (23G83). Entitlements: com.apple.developer.push-to-talk, aps-environment. Background modes: push-to-talk, audio, bluetooth-central. PTChannelManager.channelManager(delegate:restorationDelegate:) → requestJoinChannel in the foreground → didJoinChannel → setAccessoryButtonEventsEnabled(true, channelUUID:) completes without error. Audio session configured once before joining: .playAndRecord, options .allowBluetoothHFP; tried mode .default and .voiceChat. We never call setActive; audio starts only in didActivate (AVAudioEngine). What works: The system PTT UI talk button, phone locked: didBeginTransmitting → didActivate (earset HFP 16 kHz) → audio recorded. A Lock Screen / Control Center control running an intent that adopts PushToTalkTransmissionIntent, phone locked: one tap starts, one tap ends; 5+ minute transmissions; app cold-launched by the system when needed. What doesn't: pressing the earset's play/pause button (single press) while joined and idle never produces didBeginTransmitting. Same result with AirPods and with a third-party A2DP/HFP earset, locked and unlocked, Music app closed or not. mediaremoted logs, for every press: mediaremoted: Received command from client <... bundleIdentifier = com.apple.BTAvrcp ...>: <... command = Play ...> mediaremoted: No context for context-sensitive command <... command = Play, SenderBundleIdentifier = <com.apple.BTAvrcp> ...> mediaremoted: Destination app com.apple.Music not available for command <... command = Play ...> mediaremoted: Sending previously queued command <... command = Play ...> (Music is launched and plays)In thread 804205 you described this path as pressing "play" on an A2DP/HFP accessory "that's currently in playback mode". Questions: a) What exactly must be true for a headset AVRCP Play/Pause to be routed to the PTT system instead of the now-playing app? Is "playback mode" a state of our channel (e.g. only while setActiveRemoteParticipant is set / audio is playing), of the accessory, or of the route? b) Is an idle joined channel (no remote participant, nothing playing) expected to receive accessory events at all? c) Is a press-once start / press-once end mapping supported for accessory events, or is it press-and-hold only? d) If headset buttons cannot start a transmission from idle, is the BLE path (requestBeginTransmitting from a CoreBluetooth event) the only supported option for an earset trigger? (Our earset exposes no BLE button characteristic, so that would require firmware changes.) 2. Is this an appropriate use of PushToTalk? The audio goes from the user to our assistant service (speech-to-text, then the assistant responds in the app or by voice). There is no second human on the channel. In thread 816408 you noted the voice communication frameworks "can't be used for any other purpose". Would capturing a user's spoken requests/notes for an AI assistant through PTT be considered a supported use, or is PTT limited to person-to-person communication? If it isn't, is there any supported API that lets a user start and stop audio capture with an earset or a Lock Screen control while the device stays locked? A sysdiagnose and the test project are available on request. Thanks!

A Shortcuts automation with the "When I get a notification" trigger does not run for every delivered notification. There is no error or indication that a run was skipped. Repro (iPhone 16 Pro, iOS 27.0.1 (24A446)) : Create a shortcut with the "When I get a notification" trigger for Instagram and turn on its automation. Add a single "Append to Note" action that appends the notification's Title, Body, and Date. From another device, send 10 numbered DMs within about 15 seconds. Result all 10 notifications appeared in Notification Center, but only 7 entries were appended to the note (#2, #4, #6 missing). My app relies on this trigger to save notification history, and users report missing notifications. Is this trigger expected to run for every delivered notification, or is it best-effort? If anyone else sees this, filing a duplicate referencing FB25255777 would help.

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!

We're building a companion app that people use during a regular cellular call (VoIP isn't an option for this call). The user wants to briefly mute the call, speak a short question into our app, then unmute. Is there any supported way for a third-party app to record from the microphone during an active cellular call, even if the call is muted or on hold? Does Siri with App Intents accept voice input during an active call? If so, is Siri's spoken response heard by the other person on the call? Can a watchOS app record audio while the paired iPhone is on a call? If none of these work, what approach do you recommend?

I've been reading the documentation for App Intents using the @AppIntent(.tool) macro and from what I read, when an app is in the foreground the app name doesn't have to be used to trigger the App Inent. Can the app name still be eliminated if only the CarPlay Automaker app is in the foreground?

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?

Is it possible to integrate Siri into an iOS app in a way that allows users to control the app entirely through voice commands? For example, imagine a user saying: “Siri, open my add-ons and show me my available internet packages.” I would like to understand whether Siri, using App Intents or another Apple framework, can: Recognize a voice command and identify the requested action. Navigate to a specific section of the app's Home Screen, even if that section is currently outside the visible area. Automatically scroll to the relevant UI component and bring it into view. Navigate to other screens when required. Perform multiple actions as part of one continuous experience, such as scrolling, opening a screen, selecting an option, and triggering an API request. My main question is: Can we create a conversational, voice-controlled experience where a single Siri command can trigger a sequence of UI navigation and app-related operations, rather than simply opening the app or navigating to a predefined screen? What are the recommended Apple frameworks and best practices for implementing this kind of experience?

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.

On iOS 27.2, triggering RunSystemShortcutIntent from a Home Screen widget leaves all buttons in that widget unresponsive when the action does not navigate away from the current screen. Toggling the flashlight is a simple example. Steps to reproduce Add an interactive Home Screen widget with a button that uses RunSystemShortcutIntent. Trigger an action that stays on the current screen, such as toggling the flashlight. Try tapping the same button and other buttons in the affected widget. None respond. Swipe to another Home Screen page, then swipe back. The buttons respond again. Expected behavior Once the action finishes, the widget should remain responsive to subsequent taps without requiring the user to navigate away and return. Impact Based on my observations, this issue affects all apps that provide interactive widgets when the reproduction conditions above are met. A single routine system shortcut action leaves every button in the affected widget unresponsive, making important features effectively unavailable. For products built around interactive widgets, this blocks core functionality until the user switches Home Screen pages and returns. I have submitted this through Feedback Assistant: FB25377135. Given the impact on all apps that provide interactive widgets under these conditions, please prioritize investigation and a fix. Has anyone else reproduced this behavior on iOS 27.2? A consistent distinguishing symptom is that simply swiping to another Home Screen page and back restores responsiveness to all buttons in the affected widget.

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?

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

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

Hi, I am currently working on an App Transfer from Company A to Company B but can't find any documentation about what happens to existing Siri Shortcuts working via App Extension intents. I have separated the rest of the post in 2 sections: one what summarizes my current understanding and the other with some questions and hypotheses. It would be great to have either someone from Apple to answer that, or someone else share their experience and possibly some documentation that I might have missed. To my understanding, when a new Shortcut is created, it stores the BundleID of the App and of the App Extension to find the application that will execute it afterwards. If I uninstall the App, I can see a message in the Shortcut app that says "This action requires APPNAME but it may not be installed", but I know that after transferring the app the BundleID doesn't change completely, only the team part does. However, it is not possible to test that as this change cannot be done in xCode as far as I know. Another part that seems to play a role here is the info.plist file, but in my situation, there are no entries related to the BundleID. All that being said, I am wondering: Is it possible to perform an app transfer and keep previously created shortcuts working? Is it possible to test this kind of things without having to perform a transfer? I haven't found a way to change the team part of the Bundle ID Is there a place in the documentation that takes care of those things in depth?

I have been trying to create snippet views for my AppShortcuts which fill the full width of the container. Doing this via either .frame(minWidth: 0, maxWidth. infinity) or .containerRelativeFrame() work perfectly fine when my snippet is presented from Shortcuts.app (though sometimes the wrong color scheme is displayed), but when I invoke my AppShortcut from Siri AI and it presents the snippet there, it's offset on the trailing side by sometimes up to over 30 points, which has frustrating effects on the UI I am trying to implement. I've noted the insets are different too depending on whether the snippet is presented from what AppIntents method invokes it requestConfirmation or .result respectively. Here's some screenshots showing the issue. All these use the exact same snippet view, but all have different results in how they look and are inset. In App (how I want it to look) In Shortcuts (fine I guess) And finally, in the Siri app. I have reproduced this is issue and distilled it in a sample project. Please ensure this routes to the correct team: FB25164368. Thanks!

We're building a Screen Time / mindful-pause app for iOS 26–27. The user adds a Shortcuts personal automation "When is Opened" that runs our App Intent. The intent passes the trigger app's Bundle Identifier (from the trigger output) and shows a short pause screen. When the user taps "Continue", we want to take them back into that app — only the one app they chose, only after they tap. Is there a supported API to open another installed app when the user taps Continue, given its bundle identifier from the Shortcuts trigger? A DTS reply in 2024 said there was no supported way (thread 740707). Has anything changed in iOS 26/27? (Related feedback: FB15500695.) If not, is it acceptable to open the chosen app via a URL scheme it registers in its Info.plist, including a third-party sign-in callback scheme, purely to bring it to the foreground? Many apps register no URL scheme. Is there a recommended pattern — e.g. handing control back to Shortcuts so the automation or the "Open App" action opens the trigger app — without the "App is Opened" automation firing again in a loop? What's the recommended way to avoid that re-fire? We currently ignore it for a short time window. A minimal sample project reproduces this (App Intent, pause screen, Continue using UIApplication.open). Happy to share it. Xcode 27.0 (27A266a), iOS 27.0 (24A446).

Hi,I'm developing an iOS app that uses App Intents to log Wallet payment transactions via Shortcuts automation with the "After Payment" trigger. The Issue: When users set up a Personal Automation with "Run Immediately" enabled and select "Always Allow" on the permission prompt, the permission does not persist. Every subsequent Wallet transaction triggers the "Allow Once / Always Allow" dialog again. Reproduction: App exposes an App Intent (LogWalletTransactionIntent) with openAppWhenRun = false User creates Personal Automation in Shortcuts app: Trigger: Wallet → After Payment Action: Log Wallet Transaction Set automation to "Run Immediately" First Wallet payment → permission prompt appears → user selects "Always Allow" Second Wallet payment → permission prompt appears again (expected: silent execution) Observations: When the user sets up the automation manually (adds the App Intent action inline and maps fields manually), "Always Allow" works correctly — no repeated prompts The issue occurs when the action is referenced via a pre-configured .shortcut file that has variable descriptors embedded for the parameters The bundled shortcut contains Descriptor mappings for card and merchant parameters Questions: Is this a known limitation of how iOS handles permission persistence for App Intents invoked through pre-configured shortcuts vs. inline automation actions? Does the distribution method affect this behavior — will Ad Hoc (alpha), TestFlight (beta), and App Store (production) builds behave differently regarding permission persistence? Is there a recommended approach for bundling pre-configured shortcuts that avoids repeated permission prompts? Environment: iOS 18.x (also observed on earlier versions) App Intent with String and Double parameters with default:` values openAppWhenRun = false Distribution: Ad Hoc via PGY Any insights would be appreciated. Thanks!

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!