In-App Events give an app or game a time-bound discovery surface for something happening inside the product: a competition, premiere, challenge, live experience, major content release, or other eligible event.
Apple says event cards can appear on the App Store and Apple Games app, reach new users, re-engage current users, and give former users a reason to return. That is valuable, but it is not a reason to turn every routine release into an “event.”
The card, event page, deep link, and in-app destination should describe the same real experience.
Decide whether it is actually an event
Start with four questions:
- What happens? Name the activity or content.
- Why now? Define the start, end, schedule, or timely reason.
- Who is it for? New, current, lapsed, competitive, regional, or another specific audience.
- What can the person do? State the action after opening the app.
Good candidates are substantial enough to understand independently:
- a tournament or challenge;
- a live broadcast or interactive session;
- a limited-time game mode;
- a premiere or new content season;
- a major feature experience with a defined moment;
- a community or cultural event the product genuinely supports.
Weak candidates include generic promotions, routine bug fixes, vague “big updates,” and event cards that lead to a normal home screen with no relevant experience.
Define the event brief
Write one page before opening App Store Connect:
| Field | Decision |
|---|---|
| Event objective | discovery, re-engagement, redownload, participation, purchase, or another outcome |
| Audience | who should care and why |
| Event type | Apple’s most accurate purpose selection |
| Start and end | customer-visible timing and operational timezone |
| In-app destination | exact screen, state, or content |
| Eligibility | account, region, level, subscription, device, or other requirements |
| Promise | one accurate sentence |
| Creative | image or video concept that shows the experience |
| Measurement | discovery, interest, acquisition, engagement, and quality signals |
| Owner | product, marketing, creative, engineering, review, and support contacts |
This prevents a marketing card from shipping before the in-app experience and analytics are ready.
Build the in-app destination first
The fastest way to damage trust is a specific event card that opens a generic screen.
The destination should:
- recognize the event immediately;
- explain timing and eligibility;
- show the next action;
- handle users who are new, signed out, ineligible, late, or offline;
- preserve context through onboarding or sign-in where possible;
- show an accurate ended or unavailable state;
- provide support when access fails.
If the event requires an app update, subscription, purchase, registration, or region, disclose it before the person invests effort.
Use a deep link when it can reliably continue the promise. Test clean install, existing install, logged-out, returning, and expired-event paths.
Write event metadata for recognition
The visible event name and descriptions should help a person understand what is happening without decoding campaign language.
Event name
Use the recognizable activity or content. Avoid empty urgency such as “Don’t Miss Out!”
Short description
Add the key action or reason to participate. Keep it specific enough to distinguish the event from the app itself.
Long description
Explain what participants can do, material requirements, timing, and important limitations. Put the value before background story.
Badge or purpose
Choose the option that accurately describes the event. Classification helps Apple present it to relevant users; it should not be selected for perceived reach.
Timing
Make App Store timing, in-app availability, notifications, customer support, and campaign schedules agree. Test timezone boundaries and end states.
Localize meaning, dates, cultural context, and eligibility—not only words.
Design creative around the event action
The event card is small. It should make the experience recognizable without relying on tiny text.
Use:
- a focal subject or gameplay state tied to the event;
- strong contrast and simple hierarchy;
- real product or content cues;
- composition that survives cropping and device variation;
- localized assets where the visual meaning changes.
Avoid:
- generic app key art unrelated to the event;
- dense copy embedded in the image;
- prizes, people, features, or content the event does not include;
- visual urgency that obscures requirements or timing;
- a creative style that looks like another product.
Review the asset at the actual card size and beside the event name and description.
Configure and review in App Store Connect
Apple currently allows up to ten published In-App Events at a time and up to fifteen approved events per app. Events require review before they become visible.
Authorized team members can create the event, enter localized information, set timing and availability, attach assets, and submit it for review. Leave operational time for rejection, correction, and resubmission.
Before submission, verify:
- the relevant app version and destination exist;
- metadata matches the in-app experience;
- dates and regions match product availability;
- all localizations are complete and reviewed;
- assets meet current specifications;
- the event is substantial and eligible;
- support and incident owners know the launch plan.
Do not schedule the public campaign around an unreviewed assumption.
Connect the event to featuring when appropriate
If the event is part of a meaningful launch or cultural moment, attach the approved or published In-App Event to an App Store featuring nomination. Apple recommends doing this as early as possible.
The event does not guarantee featuring. It gives the editorial team a concrete, timed experience to evaluate. Use the App Store featuring guide to prepare the story, materials, localizations, and lead time.
Promote without breaking the message
Use the same audience and promise across:
- owned email, website, social, and community channels;
- creator or partner outreach;
- push notifications and in-app messages, where permitted and appropriate;
- App Store featuring nominations;
- paid acquisition and custom product pages.
The landing path should preserve context. If an external campaign promises a tournament, the App Store page and installed app should not lead with unrelated subscription copy.
Do not send every user every message. New users may need explanation and setup; current players may need the schedule; lapsed users may need to know what changed.
Measure the full event funnel
App Store Connect Analytics provides event impressions, event page views, reminder and notification activity, downloads and redownloads, app opens, subscriptions, sales, and other event-related signals. Apple notes that data appears after privacy thresholds are met.
Use five layers:
| Layer | Question | Example signals |
|---|---|---|
| Discovery | Was the event seen? | impressions, source, territory |
| Interest | Did people inspect or save it? | event page views, reminders |
| Acquisition | Did it bring or return users? | downloads, redownloads, opens |
| Participation | Did users do the event action? | entries, matches, content starts, completions |
| Quality and value | Was the experience useful? | retention, purchase, subscription, refunds, crashes, support, reviews |
Instrument the in-app event action before launch. An event-page view is not participation, and a download is not a successful experience.
Write a hypothesis:
The seven-day community challenge will bring back lapsed US players and increase completed sessions without increasing crash or support rates.
Then define audience, date range, comparison, primary measure, quality guardrails, and confounders. Featuring, paid promotion, product changes, seasonality, and notification volume can all move the result.
Learn after the event ends
Within a few days of completion:
- verify that the event is no longer presented as active;
- export the App Store and product data;
- compare results by audience and market where samples allow;
- read review and support themes;
- document operational incidents and source-mix changes;
- decide what to repeat, change, or stop;
- preserve the brief, assets, metadata, and result for the next event.
Do not call an event successful only because impressions were high. A small, relevant event can be more useful if participants complete it and return.
Common failure modes
Routine update presented as an event
There is no distinct timed action. Use release notes or promotional text instead.
Strong card, weak destination
The event opens the home screen or a paywall without context. Deep-link and state handling need work.
Hidden eligibility
Region, level, subscription, purchase, or device requirements appear only after the tap. Disclose material conditions.
Dates disagree
The App Store card, in-app timer, campaign, and support team use different timezones or end times.
Acquisition measured without participation
Downloads rise, but no event action exists in analytics. Instrument the outcome before promotion.
Too many simultaneous events
Cards compete for attention and operations. Publish only events the team can support and learn from.
Final event checklist
- The experience is a real, time-bound event rather than a routine update.
- Audience, action, eligibility, timing, and destination are explicit.
- The deep link works across install, account, region, and ended states.
- Metadata and creative accurately represent the event.
- Localizations include dates, context, assets, and product readiness.
- App Review lead time and a correction buffer are in the schedule.
- Featuring and external promotion use the same verifiable story.
- App Store discovery metrics connect to in-app participation and quality.
- Support and incident response are prepared.
- No featuring, rank, download, or revenue outcome is guaranteed.