In-App Events App Review checklist
An In-App Event is a public App Store promise about something happening inside the app. Review readiness depends on whether the event card, dates, region, and in-app destination all match.
Create an In-App Event only for a real, time-bound experience that users can reach in the submitted app. Apple requires events to be configured and approved before they appear. AppReviewReady interpretation: treat the event card as metadata under review, then prove the live in-app path with a test account, deep link, date window, and fallback state.
Confirm the event is actually event-shaped
A sale banner, evergreen feature, or generic reminder is weak event material. A strong In-App Event has a specific start, end, audience, and in-app action: a tournament, premiere, challenge, live drop, seasonal activity, class, or limited content window.
Write the user promise in one sentence before building assets. If the promise cannot name what happens, when it happens, and where the user participates, the page is likely a marketing variation rather than an event.
Make the card verifiable from the app
- Event name, short description, long description, badge, media, and region should point to the same in-app experience.
- Images should show actual event content or representative UI, not a future roadmap feature.
- The event should not require hidden credentials, private allow-lists, or manual support activation for review.
- If the event has rewards, eligibility, or purchases, those rules need to be visible before participation.
Test date and storefront behavior
In-App Events are scheduled by storefront and time window. QA should verify the discoverable date, event start, event end, and regional availability against the app's server state. A card that appears before content is ready can look broken; a card that remains after the content ends can look misleading.
AppReviewReady interpretation: run the event through a dry-run calendar with UTC and local times. Marketing calendars often use local launch language while App Store Connect and backend jobs use different clocks.
Give review a deterministic route
- Open the submitted build from a clean install and sign in with the review account if needed.
- Use the event deep link or navigation path to reach the event screen.
- Confirm the screen title, rules, rewards, media, and call to action match the App Store event card.
- Test before-start, active, ended, and unavailable-region states if the app can show them.
- Verify the event still works when push notifications, location, tracking, or purchases are denied.
Explain the event in Review Notes
The note should not argue that the event is important. It should let the reviewer verify that the App Store card reflects a real in-app state within the submitted build.
In-App Event review path: Event name: [name] Discoverable/start/end dates: [UTC] Regions: [list] How to reach in app: [steps or deep link] Test account state: [if needed] Expected result: [event screen and action] Fallback state: [before/after event]
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 event readiness
Review metadata, timing, deep links, and test access before submitting the event.
Open the tool