AlarmKit dense fan-out scheduling: alarms intermittently fire late or not at all on locked iOS 26.x device

Hi all,

I'm building an iOS alarm app on AlarmKit (iOS 26+) and running into reliability issues I can't find documented anywhere. Hoping someone here has insight.

What we're doing

We schedule a "fan-out" pattern, a single user-set alarm becomes a sequence of AlarmKit alarms firing at regular intervals over ~50 minutes. The density is needed because we require repeated wake-up alerts the user can't easily ignore until they complete an explicit dismissal action. A single AlarmKit alarm that auto-mutes after Apple's default duration doesn't solve the heavy-sleeper case.

We've seen other iOS alarm apps use a similar approach reliably on iOS 26+, so the pattern seems achievable. We're clearly missing something about AlarmKit's behavior under dense scheduling.

The issue

AlarmKit alarms intermittently fail to enter .alerting at their scheduled times when the device is locked. Lateness varies from ~20 seconds up to 4+ minutes. The bug is intermittent ie. no deterministic reproducer.

When the lateness is short (~15-22s), the next alarm in the sequence often fires only a few seconds later, suggesting the first two get bunched rather than firing independently.

When the lateness is long (minutes), our AlarmManager.shared.alarmUpdates subscriber observes zero .alerting transitions during the gap, then receives a flurry of events when the device wakes. Verified via on-thread Swift logging, not a bridge or JS-suspension issue.

Our setup

• AlarmManager.AlarmConfiguration with .fixed(date) schedule, AlarmAttributes + stop button, StopAlarmIntent, custom .named(...) sound
• No alerting duration specified (we don't believe one is exposed)
• NSAlarmKitUsageDescription set; AlarmKit authorized
• Registered WidgetExtension for the auto Live Activity
• No Critical Alerts entitlement (docs suggest AlarmKit doesn't need it)

Questions

1. Is there a documented or undocumented density limit for AlarmKit alarms scheduled in close succession?
2. What is iOS's behavior when multiple AlarmKit alarms are simultaneously in .alerting state? Coalesce? Queue? Drop?
3. Is there a supported way for the app to control per-alarm alerting duration before iOS auto-mutes?
4. For locked-overnight scenarios, are there documented power-management or dasd interactions that defer AlarmKit fires? Does declaring UIBackgroundModes fetch/processing affect this?

Any insight or a point in the right direction would be super appreciated!