Quick answer
Apple's In App Events use a 16:9 card, minimum 1920x1080, with a 30 character name and up to 10 events live at once. Google's promotional content covers offers, time limited events and major updates.
What is an event card, in plain terms?
> Quick answer: It's a second piece of store real estate you already own and probably never used. A dated card, with its own image and its own words, sitting beside your normal listing.
Apple calls them In App Events. Google calls the equivalent promotional content.
They exist so a live game or an app with news has somewhere to say it, without changing the listing everyone else sees.
And they get surfaced in places your product page never reaches.
Apple calls them In App Events. Google calls the equivalent promotional content.
They exist so a live game or an app with news has somewhere to say it, without changing the listing everyone else sees.
And they get surfaced in places your product page never reaches.
Where the cards actually appear
This is the part that makes them worth the effort.
Apple's In App Events page lists three placements. Your own product page, search results, and editorially curated or personalised selections on the Today, Games and Apps tabs.
That third one is the prize. It's a route into editorial surfaces that no amount of screenshot work will get you.
The search placement matters too. A card can appear under your app in results, which is extra height and extra reason to tap.
So the effort buys you more than a banner on a page people already reached.
Apple's In App Events page lists three placements. Your own product page, search results, and editorially curated or personalised selections on the Today, Games and Apps tabs.
That third one is the prize. It's a route into editorial surfaces that no amount of screenshot work will get you.
The search placement matters too. A card can appear under your app in results, which is extra height and extra reason to tap.
So the effort buys you more than a banner on a page people already reached.
Apple's exact numbers
Write these down, because guessing wastes a submission.
The event card image is 16:9. Minimum 1920x1080 pixels, maximum 3840x2160.
Event name: up to 30 characters, in title case.
Short description: up to 50 characters. Long description: up to 120 characters. Both in sentence case.
And you can have up to 10 events published on the App Store at one time.
Those are Apple's own published figures, not a blog's summary of them.
The event card image is 16:9. Minimum 1920x1080 pixels, maximum 3840x2160.
Event name: up to 30 characters, in title case.
Short description: up to 50 characters. Long description: up to 120 characters. Both in sentence case.
And you can have up to 10 events published on the App Store at one time.
Those are Apple's own published figures, not a blog's summary of them.
Thirty characters is the real constraint
Everything above is easy except the name.
Thirty characters is shorter than it looks on a page. "Summer Championship Weekend" is already twenty seven.
So write the name first, not last. If it does not fit, the whole event concept needs narrowing.
The short description at 50 characters is the one people underuse. It's the line that appears next to the card in most placements.
I counted the drafts on my own last event and the name went through eleven versions. The image took one.
Thirty characters is shorter than it looks on a page. "Summer Championship Weekend" is already twenty seven.
So write the name first, not last. If it does not fit, the whole event concept needs narrowing.
The short description at 50 characters is the one people underuse. It's the line that appears next to the card in most placements.
I counted the drafts on my own last event and the name went through eleven versions. The image took one.
The image is not a screenshot
The single most common mistake, and it costs the placement.
A 16:9 landscape card is not the shape of your app. Cropping a portrait screenshot into it produces a strip of interface with dead space either side.
Treat it like a poster. One subject, one idea, filling the frame.
Interface elements get laid over the top and bottom of the card in some placements, so keep your subject and your logo away from those edges.
Our device frames guide covers the opposite case, where the phone shape is the point. An event card is not one of those.
A 16:9 landscape card is not the shape of your app. Cropping a portrait screenshot into it produces a strip of interface with dead space either side.
Treat it like a poster. One subject, one idea, filling the frame.
Interface elements get laid over the top and bottom of the card in some placements, so keep your subject and your logo away from those edges.
Our device frames guide covers the opposite case, where the phone shape is the point. An event card is not one of those.
Google's version and what it covers
Google's promotional content works differently and is worth setting up separately.
Google's own documentation names the event subtypes it supports: offers, time limited events, and major updates.
That third category is the one most developers miss. A major update is an event, and most teams ship one and say nothing.
The specifications live behind further links on Google's side and change more often than Apple's, so read them at the source when you build the asset rather than trusting any blog including this one.
What does not change is the shape of the job. One image, a tagline, a description, a date range.
Google's own documentation names the event subtypes it supports: offers, time limited events, and major updates.
That third category is the one most developers miss. A major update is an event, and most teams ship one and say nothing.
The specifications live behind further links on Google's side and change more often than Apple's, so read them at the source when you build the asset rather than trusting any blog including this one.
What does not change is the shape of the job. One image, a tagline, a description, a date range.
Offers, events and updates are three different jobs
Worth separating, because the image should not be the same for all three.
An offer is a price. The number is the subject and it should be readable at a glance.
A time limited event is a moment. A character, a season, a theme. Atmosphere sells it.
A major update is a feature. Show the feature, not a celebration of the feature.
Teams that make one template and reuse it for all three get the worst of each.
An offer is a price. The number is the subject and it should be readable at a glance.
A time limited event is a moment. A character, a season, a theme. Atmosphere sells it.
A major update is a feature. Show the feature, not a celebration of the feature.
Teams that make one template and reuse it for all three get the worst of each.
Dates are the whole mechanic
An event card has a start and an end, and that is what separates it from a banner.
Set the window too long and the urgency disappears, which was the only reason the format exists.
Set it too short and you never accumulate enough impressions for the algorithm to notice.
Somewhere around a week is where most live games land, and it is a reasonable default to start from.
Plan the card before the date, not after. Approval takes time and a card that goes live on day three of a five day event has wasted itself.
Set the window too long and the urgency disappears, which was the only reason the format exists.
Set it too short and you never accumulate enough impressions for the algorithm to notice.
Somewhere around a week is where most live games land, and it is a reasonable default to start from.
Plan the card before the date, not after. Approval takes time and a card that goes live on day three of a five day event has wasted itself.
The only store asset with an expiry date
Every other thing you upload sits there until you replace it. Icon, screenshots, feature graphic, description.
An event card dies on a date you chose, and that changes how the work should be scheduled.
So it does not belong in the same batch as your listing refresh. It belongs in whatever calendar holds your releases.
I checked how teams usually get this wrong and it is almost always the same thing. The card is designed after the update ships, so it goes live late and expires on time.
Build the card in the same sprint as the feature. Not the week after.
An event card dies on a date you chose, and that changes how the work should be scheduled.
So it does not belong in the same batch as your listing refresh. It belongs in whatever calendar holds your releases.
I checked how teams usually get this wrong and it is almost always the same thing. The card is designed after the update ships, so it goes live late and expires on time.
Build the card in the same sprint as the feature. Not the week after.
Ten events at once is more than you think
Apple's cap is ten published at a time, and almost nobody gets near it.
That's not an invitation to make ten. It's a signal about the intended cadence.
Ten simultaneous events is the shape of a live service game with overlapping seasons, offers and tournaments.
For a normal app, one at a time is plenty and two is ambitious.
The trap is treating the limit as a target and shipping ten thin cards instead of one good one.
That's not an invitation to make ten. It's a signal about the intended cadence.
Ten simultaneous events is the shape of a live service game with overlapping seasons, offers and tournaments.
For a normal app, one at a time is plenty and two is ambitious.
The trap is treating the limit as a target and shipping ten thin cards instead of one good one.
What a realistic cadence looks like
Not every app should run events, and that is a fair conclusion to reach.
A live game with seasons has something new every fortnight, so the format fits naturally.
A utility app might have three genuine moments a year. Three good cards beat twelve invented ones, and invented ones get rejected anyway.
If you cannot name what changes inside the app during the event window, you do not have an event yet.
That test alone saves most of the wasted submissions.
A live game with seasons has something new every fortnight, so the format fits naturally.
A utility app might have three genuine moments a year. Three good cards beat twelve invented ones, and invented ones get rejected anyway.
If you cannot name what changes inside the app during the event window, you do not have an event yet.
That test alone saves most of the wasted submissions.
How this fits with everything else on your listing
Event cards sit alongside your screenshots, they do not replace them.
Your screenshots still do the work of explaining the app to somebody who has never seen it.
The event card answers a different question, which is why now.
So do not move your best screenshot message into an event and leave the listing thin. Our first screenshot post covers what that slot has to carry.
Two different readers, two different assets.
Your screenshots still do the work of explaining the app to somebody who has never seen it.
The event card answers a different question, which is why now.
So do not move your best screenshot message into an event and leave the listing thin. Our first screenshot post covers what that slot has to carry.
Two different readers, two different assets.
Events versus custom product pages
These get confused constantly and they solve opposite problems.
A custom product page is a different version of your listing for a specific audience, reached through a link you share.
An event card is a dated announcement that the store itself can surface to people who have never heard of you.
One is targeting. The other is discovery.
Our custom product pages guide covers the targeting side, and the two work well together.
A custom product page is a different version of your listing for a specific audience, reached through a link you share.
An event card is a dated announcement that the store itself can surface to people who have never heard of you.
One is targeting. The other is discovery.
Our custom product pages guide covers the targeting side, and the two work well together.
What gets an event rejected
The rejections follow a pattern and it is mostly honesty.
The card has to describe something that actually happens inside the app during those dates. Not a general marketing message.
The image, the name and the descriptions all have to describe the same thing. A mismatch between the picture and the words is the most common failure.
And an event that is really just an advertisement for the app itself is not an event.
Our rejected screenshot post covers the same review logic applied to your listing images.
The card has to describe something that actually happens inside the app during those dates. Not a general marketing message.
The image, the name and the descriptions all have to describe the same thing. A mismatch between the picture and the words is the most common failure.
And an event that is really just an advertisement for the app itself is not an event.
Our rejected screenshot post covers the same review logic applied to your listing images.
The measurement problem
Be realistic about what you will learn from your first one.
Event cards report impressions and taps, so you can see whether the card earned attention.
What you cannot cleanly separate is how much of the resulting install lift came from the card and how much came from the update it was announcing.
So do not judge the format on one event with a confounded result.
Run three, with the same visual approach, and compare the tap rates against each other. That comparison is clean even when the install numbers are not.
Event cards report impressions and taps, so you can see whether the card earned attention.
What you cannot cleanly separate is how much of the resulting install lift came from the card and how much came from the update it was announcing.
So do not judge the format on one event with a confounded result.
Run three, with the same visual approach, and compare the tap rates against each other. That comparison is clean even when the install numbers are not.
A workable first event
If you have never made one, do this rather than planning a campaign.
Take your next real update. Not a bug fix, a feature people asked for.
Make one 16:9 card at 1920x1080 showing that feature. Name it in under 30 characters. Set a seven day window starting on release day.
Ship it, watch the taps, and you will know more than any guide can tell you.
You can build the card art on the create page without setting up a design file for it.
Take your next real update. Not a bug fix, a feature people asked for.
Make one 16:9 card at 1920x1080 showing that feature. Name it in under 30 characters. Set a seven day window starting on release day.
Ship it, watch the taps, and you will know more than any guide can tell you.
You can build the card art on the create page without setting up a design file for it.
Frequently asked questions
What size is an App Store In App Event card?
It is 16:9, with a minimum of 1920x1080 pixels and a maximum of 3840x2160. That is a landscape frame, so a cropped portrait screenshot leaves dead space on both sides. Design it as a poster with one clear subject instead.
How many characters can an In App Event name be?
Up to 30 characters, in title case. The short description allows up to 50 characters and the long description up to 120, both in sentence case. The name is the hardest limit to work within, so write it before you make the image.
How many In App Events can be live at once?
Apple allows up to 10 published on the App Store at a time. That cap is designed for live service games running overlapping seasons and offers. For a normal app one at a time is plenty, and shipping ten thin cards is worse than shipping one good one.
What is Google Play's equivalent of In App Events?
Promotional content. Google's documentation names offers, time limited events and major updates as the subtypes it supports. The major update category is the one most teams miss, because they ship a real feature and never announce it in the store.
Do event cards replace my screenshots?
No. Screenshots explain the app to someone who has never seen it, and the event card answers a different question, which is why now. Our [Play listing asset checklist](/blog/google-play-store-listing-asset-checklist-2026) covers everything the listing itself still needs.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.