App Store In-App Events: How to Set One Up for Your Expo App (and When It Is Worth It)

App Store in-app events are Apple's way of promoting something timely that happens inside your app. Apple describes them as timely events within apps and games, such as game competitions, movie premieres and livestreamed experiences. Each event gets an event card with an image or video, the event name and a short description. Tapping the card opens an event details page with a longer description, and a note if an Apple In-App Purchase or subscription is required to take part. Events show on the App Store on iOS 15 and iPadOS 15 or later.

Two details make this more than a banner. Someone who does not have your app can download it directly from the event card or details page, and once it is installed, tapping Open takes them to the event inside the app. People can also opt in on the card or the details page to get a notification from the App Store when the event starts. That notification comes from Apple, so it reaches people who never gave your app push permission, and people who do not have it installed yet.

Apple lists three places. The one that matters most for a small app is search, because of who sees what.

Read the search row twice. When someone who already downloaded your app searches for it, the event card takes the place of your screenshots. That makes an event mostly a way to talk to people who have your app or used to have it. New users searching for your app still see the screenshots, so the work in [App Store screenshots that convert](/blog/app-store-screenshots-that-convert) is not replaced by an event.

You can also share an event with Apple's editors for promotional consideration. Apple says it highlights new apps and games, as well as those with significant updates, in-app events, cultural or seasonal moments and more. That is a request, not a guarantee. The wider picture is in [how to get featured on the App Store](/blog/how-to-get-featured-on-the-app-store).

Apple says good candidates for in-app events are challenges, competitions and special content launches. It also names three things that are not good candidates: repetitive activities such as daily tasks or rewards, price promotions that do not introduce any new content, features or goods, and general promotions that raise awareness about your app. An event can highlight a feature that is permanent, but Apple says the event itself should focus on a related limited-time moment or experience.

You pick one event badge, which displays above the title on the card and the details page. Apple offers seven:

For most apps our members build, which are habit trackers, small utilities and niche tools rather than games, two badges do nearly all the work: Challenge and Major Update. A 14-day challenge inside a habit app is a real event. A version that adds a feature people have been asking for is a real event. A bug-fix release is not, and Apple says so in the badge definition.

Inside App Store Launch Club I call this the Real Moment Test. Before anyone opens App Store Connect, the event has to pass three questions. It is Apple's own guidance turned into a checklist, plus one question Apple leaves to you.

My honest view: most first apps should not run an event in their first weeks. There is no existing audience to bring back, and the search placement is aimed at people who already downloaded the app. Get the first users through [your first 100 app users](/blog/how-to-get-your-first-100-app-users), ship something worth announcing, and then use an event for it. An event you invented to have an event tends to fail the first question, and that is the same thing Apple's reviewers are checking.

These are the numbers Apple publishes. They are worth having in front of you before you write a word of copy, because the character limits are tight.

You also enter a reference name, which is visible only in App Store Connect, and choose regional availability. You can make an event available only in specific regions and customize the dates and times for each one. Videos autoplay and repeat, so Apple suggests aiming for a seamless loop, and App Store Connect lets you preview how your media looks in the card and on the details page before you submit.

Three more settings shape how the event behaves. Event purpose tells Apple who the event is mainly for: appropriate for all users, attract new users, keep active users informed, or bring back lapsed users. Apple says this is one factor in its personalized recommendations, that it is not displayed anywhere, and that the event stays discoverable by all customers whichever you choose. Event priority decides order on your product page, where high priority events appear ahead of normal ones. Cost is where you indicate if a specific Apple In-App Purchase is required to take part. For a subscription app, Apple says you only mark this when the event costs extra on top of the standard subscription.

Events go through App Review, and Apple is specific about the metadata. One rule is stated as an outright rejection: do not include specific prices in your metadata. Apple's reason is that pricing and currencies vary across regions and can change independently of the event, and it says including specific pricing will lead to rejection by App Review.

The deep link is the part of an in-app event that is actually engineering. Apple requires an event deep link that takes people who tap Open on the card or details page to the event content inside your app. It can be a universal link, which Apple recommends for security, or a custom URL. Apple also says to avoid URL shorteners and other services that add unnecessary redirects.

For an Expo app, a universal link needs a two-way association between your website and your app. Expo's documentation describes both halves: an apple-app-site-association file hosted in the /.well-known directory of your website, listing your Apple Developer Team ID, bundle identifier and the paths that should open the app, and the ios.associatedDomains entry in your app config. Expo warns that the associated domain must not include the https protocol, and calls that a common mistake that stops universal links working. Associated domains are part of how the app is signed, so if your live version does not already have them, plan a new production build and an approved version before the event. The full walkthrough is in the [Expo deep linking guide](/blog/expo-deep-linking-guide).

Events can be submitted for review independently of a new app version, which is what makes them practical. My rule is that the event screen ships in the app first, either in the version that is already live or through [an update that does not need App Store review](/blog/how-to-push-app-updates-without-app-store-review) if the change is JavaScript only. Then the event goes to review. Submitting an event whose link opens nothing is the quickest way to waste a review cycle.

Apple's documentation lists what you enter when you create an event. In the order I work through it:

Apple also notes you can use the App Store Connect API to automate metadata upload and submission for events. For one or two events a year the web form is faster. Once the event is approved, Apple encourages you to promote it yourself through email, advertising and social media, with a link to the event's details page so people can learn more and download the app if they have not already.

App Analytics in App Store Connect reports on published in-app events. Apple says you can view downloads filtered by a specific event, acquisition sources showing where people discovered the event, engagement data such as event impressions, event details page views and app opens, and how many people chose to be notified when the event starts.

I look at two of those first. The notification count tells you before the event starts whether anyone cared about the idea. App opens tell you whether the event brought back people who already had the app, which is what the search placement is built for. Downloads from an event on a small app will be a small number, so treat one event as a single data point and not a verdict. If you want to see what people did after they landed on the event screen, that is your own tracking, covered in [how to add analytics to your Expo app](/blog/how-to-add-analytics-to-your-expo-app).

Keep a short note after each event: the badge, the dates, the notification count, the opens and what you would change. It pairs well with the test log from [App Store product page optimization](/blog/app-store-product-page-optimization). Between the two you end up with a record of what your own users respond to, which is worth more than general advice.

App Store in-app events are dated event cards that promote a timely moment inside your app on your product page, in search results and in Apple's editorial and personalized picks, on iOS 15 and iPadOS 15 or later. An event runs up to 31 days, can be promoted up to 14 days early, and is reviewed separately from your app version, with up to 15 approved and 10 published at a time. You need a badge, a 30-character name, 50 and 120 character descriptions, 16:9 card media, 9:16 details media and a working deep link. Apple says daily rewards, price-only promotions and general awareness pushes are not good candidates, and specific prices in the metadata will be rejected. Run the Real Moment Test, build and test the event screen first, then submit.

The Real Moment Test exists because the easy part of an in-app event is the form and the hard part is having something real to put in it. Inside App Store Launch Club you can post your event idea, your 30 characters and your deep link plan and get a second opinion before it goes to App Review, and the [curriculum](/curriculum) covers the build and submission steps around it. Join at applaunchclub.co for $9 a month and bring your app.