We can reproduce an AlarmKit audio failure on iPhone 16 Plus / iOS 26.6.2 (23G90) with a reduced SwiftUI app using fixed-date alarms and .default sound:
- Schedule three alarms at +60, +180 and +300 seconds.
- Leave the app visible and the phone untouched.
- The first alarm sounds. When the +180 alarm triggers, the +60 alarm is silenced (but still active). When the +300 alarm triggers, all three alarms will remain silent, however
alarmUpdatesreports one, then two, then three.alertingIDs.
A single alarm in the same binary sounded continuously for at least 3 minutes 30 seconds. The reduced app has no custom intents, widget, countdown/snooze, audio session, background modes, notifications, packages or automatic cancellation. This exact reduced binary has one recorded comparison; earlier harness configurations also exhibited the failure. Sound was observed by the tester, separately from API logs.
When +180 mutes +60, stopping the +60 alarm causes the +180 alarm banner to present itself and become audible. +300 triggering will then mute the +180 alarm. Likewise, stopping the +180 alarm will cause the +300 alarm to present itself and become audible.
If you allow +60, +180, and +300 alarms to trigger without touching the screen, all three alarms will be silent at this point. Pressing "Stop" on +60 will cause the +180 banner to present itself and become audible, "Stop" on +180 will cause +300 alarm to then present and become audible.
It is for these reasons that I believe there is a bug that occurs when an additional queued alarm transitions from "scheduled" to "active" status that causes the present active alarm to silence.
In a foreground harness run, programmatically cancelling the +60 alarm's alerting ID caused the +180 alarm to sound. However that requires app execution and does not establish a background solution.
The snooze/coincident-time report looks like it could be related. The FAQ's same-time scheduling answer also seems to describe a different case.
What is the supported audio behavior when a later alarm becomes due while an earlier one remains alerting? Is there a scheduling or handoff pattern that preserves audible delivery without requiring the app to execute at each arrival? If overlap is unsupported, which documented constraints should applications follow?
If anyone else has experienced this issue and has found a technical workaround I would appreciate hearing about it.
For any Apple staff reading this, there is more information on this issue in Feedback Assistant ID FB24757864.