Thanks Albert. Understood on FB status. Setting the bug aside, I have one API behavior question the docs don’t cover, and it’s the one blocking my shipping decision before the iOS 27 RC: on iOS 27, is it expected that AlarmManager.alarmUpdates does not emit the .alerting transition while the app is suspended, with the emission deferred until the app next gets runtime? On iOS 26 we received it at the fire minute while suspended. If deferral is the intended contract, what is the supported way for an app to react at fire time when it isn’t running?

I'm able to play custom audio and loop it. I have mine set for multiple minutes of looping. The playback is the most stable when a scheduled alarm plays in the main app's view. It's currently flaky at best, when the custom audio plays via live activity widget extension views, and routinely falls back to the single tone audio that plays "once" that others have reported on Reddit [https://www.reddit.com/r/iOSProgramming/comments/1lgam98/setting_custom_sound_in_alarmkit_doesnt_seem_to/] Something I realized today though. The main app playback works both in simulator and on a physical device. The widget extension playback WILL work in simulator, but almost always falls back to the default single tone audio when testing on a real device.

@kthchew First off, I'd like to say thank you very much for your timely reply. Second, I'd like to just say Wow! Yes, an LLM slid that in and I didn't even think to question its authenticity. I would have thought that Xcode would have told me something wasn't right and the error it did report reinforced to me that there was a legitimate entitlement missing. I removed that entitlement from the entitlements file and the error went away immediately and the app built to my device. Again, thank you so much. Who knows how much longer I would have battled this fake entitlement. Lesson learned.