In-app events are one of the quieter features in App Store Connect, and we think they're underused by small teams because the name makes them sound like something only free-to-play games with a live-ops team would bother with. That's not quite right. An in-app event is just a time-boxed card, a start time, an end time, an image, a short title, a short description, that can show up in Search results, on the Today tab, and on your own product page. If you have anything in your app that genuinely happens on a schedule, an event card is the mechanism Apple gives you to say so on the storefront itself, rather than only inside the app.
At Olnesta Ltd we think of them the same way we think of screenshots: a slot on the product page that we control, with rules about what belongs there. The rules are that it has to be an actual event, meaning it starts and ends, and that Apple reviews the card before it goes live, the same way they review a new build or a new subscription. That review step is the part worth planning around, because it means an event card is not a thing you can decide to run on Friday afternoon for the weekend.
What actually goes on a card
The card itself is small. You get an event image, a short name, a short description, and a purpose (things like a competition, a new season, a limited-time offer, a major update, and so on). You pick a start and end time, and you pick whether the card is eligible to appear in Search, on Today, and on your product page. Users can opt in to a reminder, and when the event starts they can be notified and deep-linked into your app.
A single app can run more than one event at once, and in our experience they don't need to be tightly related. A seasonal content refresh and a limited weekend challenge can coexist as separate cards with their own start and end times. What we haven't done is try to run a permanent, rolling event that never really ends, because the whole point of the feature is the deadline. An event without a real end date reads as a marketing banner, and we'd expect review to push back on that framing.
The review timing is the part to plan
Because an event card goes through review, the schedule you care about is not just the event's start time but the review turnaround before it. Our practice has been to submit event cards well ahead of when we want them live, the same way we'd submit a build we actually cared about, and to assume the review can come back asking for changes to the copy or the image.
This is also, in our experience, one of the cleaner cases for asking for an expedited review if something has to change late. Apple's own guidance around expedited review points at time-sensitive situations, and an event that goes live at a fixed hour is about as time-sensitive as it gets. We wouldn't lean on that as a workflow, it's a favor to ask for and not a lane to plan around, but if a bug turns up in the build the event depends on and the event is already scheduled, that's a legitimate reason to ask. The details of how expedited review works and when to request it live in Apple's developer documentation, and it's worth reading the current wording rather than trusting a summary, ours included.
Where it fits for a small team
We don't think every app needs in-app events, and we've shipped apps where the honest answer was that nothing in them was an event. Where it has been useful for us is when there's a concrete date on the calendar that a user might reasonably want a reminder about, a content drop, a scheduled challenge, the start of a new period inside the app. In those cases the card is doing work our release notes can't do, because it's on the storefront and Today tab where people are already browsing, and it carries a start time and a reminder button rather than just a paragraph of text.
The thing we'd tell another small studio is to treat an event card as a small release of its own. Write the copy early, have the image ready, submit with enough runway that a rejection doesn't ruin the date, and make sure the build that supports the event is either already live or in review on a compatible timeline. Used that way it's a genuinely useful surface. Used as a marketing banner in disguise, it's a review headache waiting to happen.