AlarmKit Bug: Dismissing the alarm by touching the bottom notch area.

Question

Created 2d

Replies 1

Boosts 0

Participants 1

This is about AlarmKit, and this problem is also happening with the native phone alarm.

I’m working on some alarm apps, and some users have been complaining that when they get their phone, the alarm is being dismissed. We were never able to simulate this until today.

We noticed that when touching the bottom notch of the phone, below the stop swipe area, sometimes the alarm is simply dismissed. In some cases, you can see the same UI repeated behind the screen; other times, you can’t drag, but it also dismisses the alarm. This seems to have been happening for quite a while with our users. They grab their phones, unintentionally touch that area, and dismiss the alarm. It’s very critical for us because we present other buttons on AlarmKit for the user to click on (guess which bird is singing, for example).

Feedback Ticket Created: FB24407814

Answer 1

diegofromsan francisco OP

1d

Additional findings after instrumenting our apps and reproducing this on device:

When the alarm is dismissed by touching the bottom notch area, NEITHER the stopIntent nor the secondaryIntent we supply through AlarmPresentation is executed. The app gets no callback of any kind, so we cannot distinguish an intentional stop from this accidental dismissal.
The daemon state is left inconsistent after this dismissal. The alarm's entry in AlarmManager.shared.alarms stays in the .alerting state even though the alert UI is gone and no sound is playing. We confirmed via AVAudioSession that nothing is audible while the entry still reports .alerting. A normal stop (slide to stop, or our stop intent) transitions the alarm out of .alerting, and a recurring alarm re-rolls to .scheduled.

Steps to verify the state issue: schedule a recurring AlarmKit alarm, let it fire on the locked phone, touch the bottom notch area so the alert dismisses, then read AlarmManager.shared.alarms from the app. The entry remains .alerting indefinitely until the app force-stops it.

We reproduced this consistently on iOS 26.6 (23G71) and 26.6.1 (23G82). Our production analytics also show roughly 3.5% of monthly active users hitting our defensive recovery path for stuck-.alerting entries, which matches this dismissal happening regularly in real use: users grab the ringing phone, touch that area accidentally, and the alarm dies silently.

This may be related to the reports in developer forums thread 815064 ("AlarmKit - Behaviors when dismissing alarms"), where stopIntent does not execute for some dismissal paths.

Impact: users miss the alarm flow entirely (our secondary button never runs), developers cannot tell intentional stops from accidental ones, and every affected fire leaves a wedged .alerting entry that we have to detect and force-stop defensively.