AlarmKit alerting-phase playback is significantly quieter than equivalent in-app playback using AVAudioSession(.playback)

Hi all,

I’m trying to determine whether the loudness gap I’m seeing between AlarmKit alert playback and normal app-managed playback is expected behavior, a sound-asset issue, or something that should be reported as a bug.

Observed behavior

When an alarm fires through AlarmKit while the device is locked, the alarm sound is significantly quieter than playback of the same or very similar audio once the app is active and using its own audio session.

The difference is large enough that it does not feel like a small mastering difference. It feels like the AlarmKit / system alerting path is using a meaningfully lower effective output level than normal app playback.

Test scenario

My repro is roughly:

1. Schedule an alarm with AlarmKit.
2. Lock the device.
3. Let the alarm fire and listen during the system alerting phase.
4. Enter the app / continue into the app-driven alarm experience.
5. Play the same or equivalent alarm asset via app-managed playback.

Result:

• AlarmKit / lock-screen alerting phase sounds much quieter.
• In-app playback sounds noticeably louder and fuller on the same device.

Current implementation

Alarm flow is currently split into two paths:

1) System alarm path

• Alarm scheduling and alert surfacing via AlarmKit
• Device may be locked
• No attempt to manipulate system volume
• No private APIs

2) In-app playback path

• After app activation, playback uses:

  • AVAudioSession
  • category .playback
  • AVAudioPlayer

• Audio is routed as normal app playback

• This path sounds substantially louder than the AlarmKit path

Important detail

I am not asking how to override system volume.

I understand that AlarmKit appears to follow the system ringer / alert volume model and does not expose a public API for custom alarm loudness.

My question is narrower:

Is it expected that the same asset or an equivalent asset will sound materially quieter during the AlarmKit alerting phase than during ordinary app playback with AVAudioSession(category: .playback)?

Questions

1. Is the lower perceived loudness during AlarmKit alerting an expected property of the framework / system alarm path?

2. Does AlarmKit playback use a different output path, gain policy, processing chain, or speaker treatment than normal app playback with .playback?

3. Are there recommended authoring constraints for AlarmKit alarm sounds to maximize perceived loudness on iPhone speakers?

   • transient-heavy mix
   • stronger mids
   • reduced low-end
   • different LUFS / peak strategy
   • shorter attack, etc.

4. Has anyone measured this directly with:

   • the same WAV / CAF file
   • same device
   • same system volume
   • locked AlarmKit playback vs unlocked in-app playback

5. If this is not expected, would Apple want this reported as a bug with:

   • sample project
   • exact iOS version
   • device model
   • screen recording / audio recording

What I’m trying to figure out

For alarm-app UX, this matters a lot because:

• AlarmKit is the most reliable lock-screen/system path.

• But if AlarmKit playback is substantially quieter than normal app playback, the alarm experience is inconsistent depending on device/app state.

• That makes it hard to know whether to treat this as:

  • expected system behavior,
  • a framework limitation,
  • an asset/mastering problem,
  • or a bug.

If anyone has tested this in a controlled way or received guidance from Apple/DTS, I’d appreciate any technical detail.

Thanks.