AlarmKit leaves an empty zombie Live Activity in Dynamic Island after swipe-dismiss while unlocked

Question

Created 1d

Replies 1

Boosts 2

Participants 2

Hi,

We are the developers of Morning Call (https://morningcall.info), and we believe we may have identified an AlarmKit / system UI bug on iPhone.

We can reproduce the same behavior not only in our app, but also in Apple’s official AlarmKit sample app, which strongly suggests this is a framework or system-level issue rather than an app-specific bug.

Demonstration Video of producing zombie Live Activity

https://www.youtube.com/watch?v=cZdF3oc8dVI

Related Thread

Environment

iPhone with Dynamic Island
Alarm created using AlarmKit
Device is unlocked when the alarm begins alerting

Steps to reproduce

Schedule an AlarmKit alarm.
Wait for the alarm to alert while the device is unlocked.
The alarm appears in Dynamic Island.
Instead of tapping the intended stop or dismiss button, swipe the Dynamic Island presentation away.

Expected result

The alarm should be fully dismissed.
The Live Activity should be removed.
No empty UI should remain in Dynamic Island.

Actual result

The assigned AppIntent runs successfully.
Our app code executes as expected.
AlarmKit appears to stop the alarm correctly.
However, an empty “zombie” Live Activity remains in Dynamic Island indefinitely.
The user cannot clear it through normal interaction.

Why this is a serious user-facing issue

This is not just a cosmetic issue for us. From the user’s perspective, it looks like a Live Activity is permanently stuck in Dynamic Island.

More importantly:

Force-quitting the app does not remove it
Deleting the app does not remove it
In practice, many users conclude that our app has left a broken Live Activity running forever
We receive repeated user complaints saying that the Live Activity “won’t go away”

Because the remaining UI appears to be system-owned, users often do not realize that the only reliable recovery is to restart the phone. Most users do not discover that workaround on their own, so they instead assume the app is severely broken.

Cases where the zombie state disappears

Rebooting the phone
Waiting for the next AlarmKit alert, then pressing the proper stop button on that alert

Additional observations

Inside our LiveActivityIntent, calling AlarmManager.shared.stop(id:) reports that the alarm has already been stopped by the system.
We also tried inspecting Activity<AlarmAttributes<...>>.activities and calling end(..., dismissalPolicy: .immediate), but in this state no matching activity is exposed to the app.
This suggests that the alarm itself has already been stopped, but the system-owned Live Activity UI is not being cleaned up correctly after the swipe-dismiss path.

Why this does not appear to be an app logic issue

The intent is invoked successfully.
The alarm stop path is reached.
The alarm is already considered stopped by the system.
The remaining UI appears to be system-owned.
The stuck UI persists even after our own cleanup logic has run.
The stuck UI also survives app force-quit and app deletion.

Boost

Answer 1

this_mischa OP

1d

Thank you for sharing your analysis and this well-structured post!

I can confirm these findings and apparently, this is what's causing the blank live activity I described in my post as well.

Judging from your observations, I agree with the assessment that this seems to be an issue inside the framework. This information should help the engineers at Apple to identify and fix it.

0