An in-app event is a card Apple will show for a timed thing happening inside your app — a competition, a season, a premiere, a live stream. Apple puts that card in places your product page cannot reach on its own.
Most developers never use them, and the two reasons are usually that the rules are scattered across several App Store Connect Help pages and that the scheduling has a set of hard constraints you only discover by tripping over them. So here is the whole set, fetched from Apple's own documentation for this post.
The limits
Every figure below comes from App Store Connect Help — the Offer In-App Events page — verified by page title, not by HTTP status. (Worth knowing if you check Apple's docs yourself: Apple's /help paths return HTTP 200 for URLs that do not exist, serving a "Page Not Found" body. A 200 proves nothing.)
| Field or rule | Apple's limit | Who sees it |
|---|---|---|
| Reference name | 64 characters | Nobody — internal to App Store Connect |
| Event name | 30 characters | Public |
| Short description | 50 characters | Public — the card in Search and the Today tab |
| Long description | 120 characters | Public — the event details page |
| Published at once | 10 events | — |
| Approved in App Store Connect | 15 events | — |
| Minimum duration | 15 minutes | — |
| Maximum duration | 31 days from the start date | — |
| Publish in advance | up to 14 days before the start | — |
| Per-region start times | all within 48 hours of each other | — |
Apple lists four places an event card can appear: the Today tab, Search, your product page, and the event's own details page.
Fifty characters is the whole pitch
Look at that table again and notice the asymmetry. The long description gets 120 characters and appears on a page somebody has already chosen to open. The short description gets 50 and appears in Search and the Today tab — which is to say, in front of people who have not decided anything yet.
Fifty characters is about eight words. It is shorter than this sentence. And it is the only copy most people who ever encounter your event will read.
The practical consequence: write the short description first, in isolation, and check that it stands up without the event name above it or the app around it. "Season 4 starts Friday" works. "Don't miss out on our biggest update yet" is forty of your fifty characters spent saying nothing.
Appstro's in-app events planner renders an indicative Search card at that length for exactly this reason. It is labelled indicative rather than a pixel copy of Apple's layout, because the point is not to mock up Apple's design — it is to see whether fifty characters carries the idea.
The scheduling mistakes
Five of the constraints above are the ones that actually catch people, and each has a distinct failure:
- End before start. Rejected outright.
- Under 15 minutes. Apple's floor. A flash event of ten minutes is not an event.
- Over 31 days. The end date can be at most 31 days from the start, so a "season" that runs six weeks is two events, not one.
- Publish date after the start date. The card goes live after the thing has begun, which is not a promotion.
- Publish more than 14 days early. Apple's ceiling on lead time.
And one more that Apple does not forbid but that costs you the whole point: publishing less than a day before the event starts. That is legal and it leaves no window for anyone to find the card. It is not a rule, it is a reach problem, and it is worth treating as a warning rather than an error — sometimes a same-day event is genuinely what you meant.
The distinction matters when you are building a checker. Errors should be things Apple rejects. Everything else is advice, and advice that pretends to be a rule teaches people to distrust the rules.
Badges are validated as present, never as correct
Apple asks you to choose a badge that describes the type of event, and documents the available options in its in-app events specifications. What no tool can check is whether you chose the right one.
Whether your Challenge is genuinely a challenge, or is really a Special Event with a leaderboard bolted on, is a judgement about your app that nothing outside your app can make. A mismatch is not a validation failure you will see before submitting — it is rework at review. So the useful thing a planner can do is put Apple's own definition next to each badge and let you decide, rather than scoring the choice.
Two figures that are rules, not readings
The 10-published and 15-approved limits are Apple's constraints. They are not a count of what is currently in your account, and nothing outside App Store Connect can see that.
That sounds pedantic until you are planning a quarter of events against a limit and want to know how many slots you have left. The answer is in App Store Connect, and only there.
What this cannot tell you
- Not whether events help you rank. Apple publishes no such factor and this post does not assert one. What is documented is where the card appears — Search, the Today tab, your product page, the event page. That is a placement claim, which is verifiable, rather than a ranking claim, which is not.
- Not how many people will see it. Apple's editorial placement in the Today tab is Apple's decision.
- Not whether your event is any good. Character counts and a schedule check are arithmetic. Whether the thing you are promoting is worth promoting is not.
- Not your current event slots. See above.
The work
Draft the short description first and read it cold at fifty characters. Then run the whole thing — name, both descriptions, badge and schedule — through the in-app events planner and fix the arithmetic before you get anywhere near App Store Connect. Every limit it checks is Apple's, and every one of them is on the page linked above if you want to read them at the source.