App Store In-App Events in 2026: A Step-by-Step Tutorial for Event Cards, Badges, and Review

Apple describes an In-App Event as a timely event inside your app — a competition, a premiere, a live-streamed session, a new season. The unit users see is the event card: an image or video, a badge, the event name and a short description. Tapping the card opens an event details page with a longer description, which is where the actual pitch happens.

Surfaces Apple names explicitly: the Today tab, search results, your product page, and Apple Games. Because the card competes with editorial content in those slots, Apple reviews each event before it becomes visible — an approved event is a separate approval from your app binary, and a live app does not get events approved automatically.

• Availability requires iOS 15 or iPadOS 15 and later on the viewer's device.
• The event does not require a new app version; it does require the in-app content to actually exist at the start date.
• Events are per app, not per account: the ceilings below apply per app, and events never carry across apps.

The badge is the smallest element on the card and the one that decides whether the event reads as news. Apple's reference lists exactly seven, each with its own intent:

• Live Event — real-time activity all users can experience simultaneously, such as a sports match or a live-streamed concert. Apple expects new content, features or goods.
• Premiere — first-time availability of content or media, such as a newly released movie or audio.
• Challenge — a goal the user is encouraged to reach before the event ends, such as a fitness challenge or clearing a set number of levels.
• Competition — users competing against one another for ranking or rewards, such as a tournament.
• New Season — new content, storylines or media libraries, such as a new season of a show or a new battle pass.
• Major Update — significant new features, content or experiences, such as new game modes or levels. Apple's wording explicitly excludes minor enhancements like UI adjustments or bug fixes.
• Special Event — limited-time events the other badges do not capture, possibly spanning several activities, such as a collaboration.

The recurring rejection pattern is a Major Update badge on a maintenance release, or a Live Event badge on pre-recorded content. Read the badge as a promise the user can verify inside the app within seconds of tapping. If the promise does not hold when the card is tapped, the event damages the listing instead of promoting it.

App Store Connect asks for four text values, and only three of them are public. The caps are not advisory; the field stops accepting characters.

1. Reference name — internal only, never shown on the App Store, unique per app, up to 64 characters. Use a convention you can sort: 2026-05-27-major-update-season-3 beats "Spring push final v2".
2. Event name — shown on the card and the details page, up to 30 characters.
3. Short description — shown on the card in places like the Today tab and Search, up to 50 characters.
4. Long description — shown on the event details page once the card is tapped, up to 120 characters.

Buy the space deliberately. Thirty characters is a name, not a sentence. Fifty characters is one benefit with a concrete noun — what is new, for whom. One hundred and twenty characters is where you say what opens, when it closes and what a returning user gets that a new user does not. Writing the 120 first and trimming down to 50 usually produces a better card than writing the 50 first and padding it.

Character counts include spaces and punctuation, and localizations are counted per language — a 30-character English name is often a 20-character Japanese one and a 34-character German one. Trim before you translate, not after.

Five scheduling constraints do most of the damage, and all five are mechanical:

• The start date can be any date in the future. A start date in the past cannot be recovered by editing.
• The end date can be at most 31 days after the start date.
• An event must be at least 15 minutes long.
• The publish date — when the card becomes discoverable — can be at most 14 days before the start date. Publishing earlier than that is not available; publishing later costs you the discovery window you wanted.
• You can have at most 10 events with overlapping start dates and times, whether approved or still in draft.

If you use per-country start times, Apple requires all of your event start dates to fall within 48 hours of each other. That ceiling is what turns a global rollout into a two-day window rather than a two-week one, and it is the constraint most often discovered after the artwork is finished.

Per Apple's current App Store Connect help: you can publish up to 10 In-App Events on the App Store and Apple Games at a time, and you can have up to 15 approved In-App Events per app in App Store Connect at a time.

The gap between ten and fifteen is your buffer, not your plan. Fifteen approved events can exist, but only ten can be live simultaneously, so the five extra are either waiting for a slot or sitting approved and unscheduled. If you are running a season of weekly events, map the calendar against both numbers before you design anything: ten live events across 31-day windows is a much tighter budget than it sounds.

Approval is the gate: an event must be approved before it is visible to users. Review is a separate submission from the app binary, which also means a live, healthy app can still have an event come back rejected — and a rejected event does not affect the app's status.

1. Open App Store Connect and go to My Apps, then select the app.
2. In the left sidebar, under Features, click In-App Events. The overview lists drafts, approved events and past events.
3. Click the add button (+) and enter the internal reference name, then click Create.
4. Enter the public event name (30 characters) and the short description (50) and long description (120).
5. Upload the media for the card and the details page, or use Browse Assets to pull approved, compatible images and videos from your Asset Library.
6. Choose the badge that matches what the user will actually find.
7. Add localizations. The primary language is the default for users whose device language you have not localized, so pick it deliberately rather than by habit.
8. Set country or region availability, then the start and end dates and times. If you start on different days in different regions, keep every start inside Apple's 48-hour spread.
9. Set the publish date and time — remember the 14-day ceiling ahead of the start — then click Save and submit the event for review.

Two habits worth adopting: build the media before the copy, because the card is image-first and the 50-character line exists to fit the art, not the other way round; and keep the reference name in date order so a queue of events is readable at a glance when you are juggling the ten-event ceiling.

Events localize separately from the app listing. A fully translated store listing does not translate an event, and an event left in one language shows that language to every storefront — Apple's help is explicit that the primary language displays to users whose device language you have not localized.

In practice that means the badge (which Apple renders in the storefront language), the event name and both descriptions each need their own pass per locale. The card art usually carries English text baked into the image; if you ship the same art to every storefront, the localized 50-character line has to live with art it does not match. Either build one art set per major locale or keep the art text-free and let the copy do the work.

Once an event is submitted, the editability rules tighten in three stages, and knowing them prevents the worst outcome — an approved event with a typo and no way to fix it without starting over:

• While the event is Waiting for Review or In Review, you must remove it from review to change anything except Country or Region Availability.
• Once the event is published on the App Store, only the start and end dates can be modified.
• After the event begins, you can adjust the end date only.

Events also expire into Past Events, where you can archive them. The useful side effect of Apple's Asset Library is that approved media can be reused for later events, so a well-produced card is not a one-shot asset — but the copy is.

The failure modes cluster into eight groups. Every one of them is cheaper to fix before submission:

1. Badge inflation. A Major Update badge on a bug-fix release; Apple's own description excludes minor enhancements.
2. No in-app destination. The card promises a mode, tournament or library that is missing, hard to find, or requires a purchase the copy did not mention.
3. Dates that cannot work. Start in the past, runtime over 31 days, publish date more than 14 days ahead, or regional starts spread beyond 48 hours.
4. Capacity blindness. Eleven events with overlapping starts, or a season planned against 15 approved slots while only 10 can be live.
5. Copy that ignores the caps. A 30-character name that is a full sentence, or a 50-character line that repeats the name instead of adding information.
6. Localization gaps. English-only cards in non-English storefronts, or translated names that overflow the card layout.
7. Art that lies or borrows. Prices, discount percentages, badges-not-badges, or third-party trademarks and characters that are not licensed to you.
8. Editing after submission. Discovering a problem while the event sits In Review and losing the whole review window instead of the eleven seconds it would have taken to proofread first.

There is also a quieter failure that no review catches: an event that runs perfectly and converts nobody because the card sells a feature instead of a moment. The badge says New Season; the card should say what is new this week, who it is for, and what happens if you tap. That is a copy problem, and it is solvable in 120 characters.

In-App Events sit on top of an account that has to be healthy first. The event needs an approved app, a live storefront, consistent legal and tax records behind the account, and a team with the right App Store Connect roles — a Marketing role can work on events while a Developer role cannot touch money. When we operate accounts for developers, events are treated as listing operations with the same discipline as a version release: a scheduler with the 14-day and 31-day rules baked in, copy written to the character caps, per-locale media, and a submission slot that leaves room for a rejection round.

What we do not do is submit an event that promises something the app cannot deliver. Apple's review is not the risk; the tap after the review is.

Sources: Apple Developer — App Store Connect Help, Offer In-App Events, Overview of In-App Events, Manage events; App Store Connect Reference — In-App Event badges, In-App Event media specifications. Limits and character caps are as published by Apple at the time of writing and can change; check the help pages before you plan a season.