Hey everyone,
We're using Push to Start Live Activities in our app (District: Movies Events Dining) where all Live Activities are entirely server-driven.
At District, we've taken a unique approach to Live Activities. Since our customers often plan ahead reserving restaurant tables early in the week or booking movies days in advance we needed a way to surface timely, relevant information without requiring the app to be open.
We power our Live Activities entirely from the server using Push to Start and Push to Update. This means the Live Activity is initiated and kept up to date by our backend from reservation confirmation all the way to the day of the experience. Whether it's a dining slot or a movie showtime, the Live Activity automatically appears in the notification tray with all relevant details, right when you need it no app launch required.
FB Number: FB22062904
Problem:
When a Push to Start payload is sent from the server, the user sees an Allow / Don't Allow prompt on their lock screen.
If the user ignores this prompt (neither taps Allow nor Don't Allow), the Live Activity card stays stuck in the notification tray permanently with zero way to dismiss it programmatically.
This happens because:
- The activity never officially "starts" on device
- Activity.end() cannot be called — there's nothing to end
- Sending an update/end push has no effect
- dismissal-date is not honoured in the start payload
Steps to Reproduce
- Send a push-to-start APNs payload to a device
- Do NOT tap Allow or Don't Allow on the prompt
- Observe — card stays in notification tray indefinitely
- Send an end push from server — no effect
Current Payload
{ "aps": { "timestamp": 1234567890, "event": "start", "alert": { "title": "Your table is reserved", "body": "Tap to view your reservation" }, "content-state": { ... }, "attributes-type": "ReservationActivityAttributes", "attributes": { ... } // ❌ dismissal-date has no effect here } }
Expected Behaviour
dismissal-date should be honoured in the push-to-start payload, so that if the user ignores the prompt, the notification auto-dismisses after the specified time — consistent with how standard Live Activity expiry works.
Suggested Fix
{ "aps": { "timestamp": 1234567890, "event": "start", "content-state": { ... }, "dismissal-date": 1234568490 // ✅ honour this } }
Impact
This affects any app using server-driven Live Activities — dining reservations, movie bookings, food delivery, ride hailing, ticketing etc. Without this, there is no way to prevent permanent notification tray pollution for users who ignore the Allow prompt.
Has anyone found a workaround for this? Would love to know if others are hitting the same issue.