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.

On a physical iPhone running iOS 27.0.1, an AlarmKit alarm due while the device was powered off sounded immediately after restart, approximately two minutes after its deadline, before the first passcode entry or app launch. We observed this with both fixed(Date) and relative hour/minute with repeats: .never. A normal control rang on time. Inspection of the public AlarmKit interface in iPhoneOS SDK 27.0 found no expiry parameter. Is this overdue replay expected? Is there a supported validity window or guaranteed pre-presentation mechanism that suppresses expired opportunities while retaining valid future opportunities? Cleanup after app launch is too late. Should this be filed as a bug or enhancement request?