In-app events and promotional content
In-app events are time-boxed announcements that appear as cards on your App Store product page, in search results and potentially on the Today tab — a live tournament, a seasonal challenge, a premiere or a major update. Each event carries its own 30-character name, 50-character short description, 120-character long description and event card image, all of which Apple indexes, so an event is additional discoverable surface rather than just a banner. You can run up to five approved events at a time, each lasting a maximum of 31 days. Google Play's counterpart is promotional content, which surfaces events on the Play Store and requires an active, non-trivial event to be accepted.
Key takeaways
- Apple in-app events are indexed, so each one adds a small amount of extra keyword surface.
- Up to five events can run concurrently; each lasts a maximum of 31 days.
- Events are reviewed like metadata and can be rejected for promotional or misleading copy.
- Events reach three audiences separately: people who have never installed, current users, and lapsed users.
- Google Play promotional content is the Android equivalent and requires a genuine, time-bound event.
Event fields and limits
| Field | Limit | Indexed? |
|---|---|---|
| Event name | 30 characters | Yes |
| Short description | 50 characters | Yes |
| Long description | 120 characters | Yes |
| Event card image or video | Required | No |
| Duration | Up to 31 days | n/a |
| Concurrent events | Up to 5 approved | n/a |
Which events are worth running
- Challenges and competitions: the strongest performers, because they carry a deadline the user can act on.
- Live events and premieres: streams, tournaments, launch moments with a fixed start time.
- Major updates: a substantial new capability, framed as something to come back for rather than a changelog.
- Seasonal content: recurring calendar moments you can plan a year ahead and reuse.
- Special offers: allowed, but the copy must describe the experience rather than read as an advertisement.
Planning a calendar
Events reward regularity. A predictable cadence — monthly at minimum — keeps a card permanently on your product page and gives lapsed users a recurring reason to return, which lifts reactivation independently of any acquisition work.
Because events are reviewed, build in lead time. Submit at least a few days before the intended start, and keep a fallback image and copy ready in case a card is rejected close to a launch date.
Worked example: a language app running a seasonal challenge
A language-learning app ran a two-week January challenge as an in-app message and nothing else. Existing users saw it, engagement rose for a fortnight, and the store showed no trace of it. The same challenge, submitted as an in-app event, becomes an indexed card that appears in search results and on the product page — the difference between an internal campaign and an acquisition surface.
The second run was submitted eleven days before the start date, which cleared review with room to spare. The event card led with the outcome rather than the mechanic — 'Learn 300 words in 14 days' rather than 'January Challenge' — because the card is read by people who have never opened the app and have no idea what the challenge is. Event names that assume prior context convert only the audience you already have.
The measurable effect showed up in two places. New installs attributed to the event card gave a direct read on acquisition, and the product page itself converted better for the fortnight the card was live, because a dated event is social proof that the app is actively maintained. Both effects ended when the event did, which is the argument for a calendar rather than a one-off.
Mistakes that waste an event slot
Most events underperform for procedural reasons rather than creative ones. The recurring failures:
- Submitting inside the review window, so the event goes live days into the promotion or not at all.
- Naming the event after an internal campaign name that means nothing to a non-user.
- Reusing one event card image across every event, which removes the freshness signal the surface exists to give.
- Running events only for major seasons, when a steady cadence of smaller events holds the visibility better.
- Failing to set the end date deliberately, leaving an expired event as the most recent thing on the page.
- Treating the event as engagement-only and never reading its install attribution, so the acquisition value stays invisible to whoever funds the work.
Frequently asked questions
Do in-app events help App Store rankings?
Indirectly. The event fields are indexed and add discoverable surface, and events lift engagement and reactivation — both of which feed the signals Apple uses for ranking.
How many in-app events can run at once?
Up to five approved events can be live simultaneously, each running for a maximum of 31 days.
What is the Google Play equivalent of in-app events?
Promotional content. It surfaces time-bound events on the Play Store and requires a genuine event rather than routine marketing.
appXL Research
App Store Optimization Research Team
The appXL research team analyzes App Store and Google Play ranking data across the apps our agent manages, and publishes what it finds.