Live Activities App Review checklist
A Live Activity is visible outside the app, often on the Lock Screen. That makes timeliness, privacy, and lifecycle control part of the review surface.
Use Live Activities only for ongoing, time-bounded tasks where glanceable status helps the user. Apple ActivityKit supports starting, updating, and ending activities, including with push updates. AppReviewReady interpretation: review the full lifecycle: who starts it, what data appears, how it updates, how it ends, and where a tap lands.
Validate the ongoing activity use case
A Live Activity should track something happening now: a ride, delivery, workout, timer, order, score, recording, route, or reservation. It should not be a persistent ad, generic reminder, or replacement for opening the app.
Write the activity's start condition and natural end condition before implementation. If the team cannot name when it should end, the activity may become stale or intrusive during review.
Test start, update, and end states
- Start the Live Activity from a user action, not from a surprising background event.
- Update it with realistic timing, including delayed network responses and app relaunch.
- End it when the task completes, expires, is canceled, or becomes unavailable.
- Tap the activity and confirm the app opens to the matching task state.
- Verify multiple simultaneous activities, if supported, do not confuse labels or deep links.
Keep visible data appropriate for locked devices
Lock Screen and Dynamic Island content can reveal private information to nearby people. Avoid sensitive health, finance, child, location, identity, or message content unless the user clearly chose that exposure and can stop it.
AppReviewReady interpretation: run a 'stranger glance' test. If the activity text would reveal something harmful when seen by another person, redesign the visible summary or require a more private setting.
Constrain push updates and payloads
- Send only fields required to update the activity view.
- Handle dropped, delayed, duplicated, and out-of-order updates gracefully.
- Do not use Live Activity updates as a marketing notification channel.
- Make server-side expiration and cancellation match the app's local state.
Give reviewers a trigger path
If the activity depends on a real-world event, provide a test mode or sample order so review can see the lifecycle without waiting for production operations.
Include a stale-state expectation as well. Reviewers may leave the device idle, background the app, or return after the activity should have ended. The submitted build should show a completed, canceled, or expired state rather than pretending an old task is still live.
Finally, compare the Live Activity text with notification copy and in-app status labels. A delivery, score, ride, or timer should not use three different words for the same state, because mismatched labels make the outside-app surface look unreliable.
Live Activity review path: Activity type: [delivery, timer, game score] How to start: [steps] Expected updates: [timing] How to end: [steps or wait time] Tap destination: [screen] Private data shown: [none or reason] Push update test: [if applicable]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check Live Activity risk
Review lifecycle, privacy, push updates, and tap behavior before submission.
Open the tool