AlarmKit — system-owned alert timeout and unattended repeat behavior

Question

Created 1w

Replies 2

Boosts 0

Participants 3

I am testing a native AlarmKit prototype on a physical iPhone running iOS 27.0.1. The current build uses Xcode 26.6 / iPhoneOS SDK 26.5; a separate successful CI inspection of Xcode 27.0 / iPhoneOS SDK 27.0 found no alerting-timeout or expiry parameter. I use public APIs only.

Normal scheduled alarms, manual Stop, and user-triggered countdown snooze work while the phone is locked. A bundled 10-second custom WAV plays, but audible alerting continued beyond 15 seconds until manually stopped. I understand that preAlert/postAlert are countdown intervals and that a sound file's length is not an alert timeout.

Is there a supported system-owned setting or architecture to end audible alerting after a configurable duration (for example 10 or 11 seconds), without user interaction, while the app is suspended or not running? If supported, can that timeout transition into another alarm/countdown after a configurable interval, with a bounded repeat count, while Stop cancels the remaining opportunities for the same occurrence?

I have not found a documented maximum alerting-duration parameter. I am not seeking a Timer, Task.sleep, background-refresh timing assumption or ongoing background-audio workaround. Preregistering multiple alarms also raises overlap and cleanup issues.

If cancellation of preregistered sibling alarms from stopIntent is recommended, what execution guarantees apply when dismissal is via the system Stop UI or a physical button, particularly after reboot before the first unlock? Does AlarmKit provide an atomic system-owned alternative to scheduling the next alarm and then stopping the current one?

Please distinguish documented behavior from a best-effort approach. Guidance on whether these requirements need an enhancement request would be helpful.

Answer 1 · 1w

Pokpong OP

1w

I checked the public AlarmKit configuration APIs too. The documented preAlert and postAlert values control the countdown before an alarm fires and the countdown after a person snoozes it. They are not limits on how long the alert sound plays. The alarm configuration exposes the sound and stop or secondary intents, but I can't find a public alert-duration or automatic stop setting.

A stopIntent is for handling the person's Stop action. It isn't a timer that AlarmKit runs after the sound has played for a set number of seconds, so I wouldn't rely on it to implement an unattended 10-second cutoff. The WWDC session also describes the countdown intervals as the time before the alert and the time before it fires again after snoozing.

I also wouldn't assume a chain of preregistered alarms can be cancelled atomically when the system Stop UI or hardware button is used, especially across reboot and before first unlock. The docs describe managing alarms individually, and note that some Live Activity UI isn't available before first unlock. If those exact guarantees matter, I'd ask DTS and file a Feedback Assistant request for a system-owned alert timeout and repeat policy.

References: AlarmManager.AlarmConfiguration and Wake up to the AlarmKit API

Answer 2 · 1w

DTS Engineer OP

Apple

1w

@Someone77

Thanks for the post. A few ideas if I may.

I do not see an API to automatically end audible alerting after a configurable duration without user interaction while the app is suspended or not running. While is running you could trigger a timer to call https://developer.apple.com/documentation/alarmkit/alarmmanager/cancel(id:)

Because alarms are designed fundamentally to ensure the user is awakened or alerted, the system expects explicit user interaction to dismiss an actively ringing alarm.

If you attempt a best-effort approach by preregistering multiple sibling alarms, like scheduling occurrences at 10-minute intervals to simulate an auto-snooze you may encounter significant execution constraints as I don’t think that was the intended designed for the API.

When the device is unlocked, dismissing the alarm via the system Stop UI or a physical button will invoke your code allowing you to cancel the pending sibling alarms.

AlarmKit does not provide an atomic, system owned alternative to scheduling the next alarm and stopping the current one. You can use the pause and cancel API and manage all the alarms while your app is running https://developer.apple.com/documentation/alarmkit/alarmmanager/stop(id:)

Albert  WWDR