YDMmobile / oss

A Year-Old AlarmKit Beta Report Became a Product Constraint

2026-09-30

An AlarmKit evaluation found two apparent limits: custom audio could play for only 30 seconds, and it would play once.

Those limits mattered. A wake-up sound that stops politely after one short clip is not much of an alarm (it is closer to a notification with ambition).

So the product discussion started bending around them.

Then a physical-device test used a 44.4-second CAF file. It played all 44 seconds, returned to the beginning, and kept alerting after the app card had been swiped out of the app switcher.

The product constraint was not in AlarmKit. It was in an old beta report.

The sources were not equally current

Apple introduced AlarmKit for iOS and iPadOS 26. The official AlarmKit documentation and WWDC25 session 230 establish authorization, scheduling, system presentation, custom actions, and named alarm sounds.

They did not answer every operational question. Duration and repeat behavior were important gaps for this product.

Developer forum reports appeared to fill them. One report had been written against an iOS 26 beta in August 2025. A later thread included an Apple engineer saying that the custom-sound defect was being fixed in 26.1.

That timeline should have changed the confidence level immediately:

beta observation in August 2025
  != documented contract
  != measured behavior on a later iOS release

Instead, the old observation was treated like a stable platform limit.

The device test was deliberately narrow

The corrective measurement ran on September 3, 2026, using an iPhone 16 Pro on iOS 26.6.1. The alarm used a 44.4-second bundled CAF file through sound: .named(...).

The observed result established three facts for that setup:

  • The file played beyond 30 seconds.
  • Playback looped back to the start.
  • The alarm continued after the app card was removed from the app switcher. Process death was not independently confirmed.

That is enough to reject “30 seconds maximum” and “plays once” as current universal constraints.

It is not enough to claim that every sound configuration works.

What the test did not prove

Several questions remain open.

AlarmKit accepts a default sound or a named sound. Apple's WWDC material names the main bundle and Library/Sounds as locations, while the recorded project evidence exercised only a bundled file.

The test did not prove:

  • that copying a user recording into Library/Sounds works for this flow;
  • that AlarmKit accepts the app's MP3 assets;
  • that playback has no ceiling above 44.4 seconds;
  • how AlarmKit audio composes with an active app-owned AVAudioSession;
  • whether the app receives interruption or route-change notifications at alarm start and end.

Those are [PARTIAL] or [UNKNOWN], not inconvenient details that can be filled with confidence.

Documentation gaps need expiry dates

When official documentation leaves a behavior unspecified, community reports are useful. They are also perishable.

I now record four fields beside any platform observation that could shape a product decision:

  1. The exact OS build and device.
  2. Whether the source describes a beta or stable release.
  3. The date and setup of the observation.
  4. The condition that requires remeasurement.

For this AlarmKit question, a later stable release and a product-critical behavior both demanded a new device pass.

The rule is not “ignore forum reports.” The rule is “do not promote a dated observation into a permanent API contract.”

Separate the closed question from the open ones

The best outcome of the test was not that AlarmKit became fully understood. It was that one broad uncertainty became several smaller statements.

Closed for the measured setup: a 44.4-second bundled CAF can play fully, repeat, and continue after the app is swiped out of the app switcher.

Still open: confirmed process-termination behavior, file locations beyond the bundle, MP3 behavior, longer durations, file replacement, reboot behavior, and interaction with app-owned audio.

That split is actionable. The product no longer needs a workaround for an observed 30-second stop. It still needs focused tests for user recordings and audio-session composition behavior.

If an old beta report is carrying a current product decision, put it on a device before putting it in the roadmap.

The test may confirm the limitation. Or, as in this case, it may remove a product constraint that was never part of the current platform behavior.