Overview
An in-app event is a timed, discoverable moment on your App Store page: a launch, a competition, a season. It has its own art, its own copy and its own schedule.
Creating an event
The list splits into Draft and Published in the top bar. New event sits on the right of that bar, opens the form, and Create saves it. An event carries a badge, a name, a short description, a longer description, art and a schedule.
Like a listing change, an event is submitted and reviewed rather than going live the moment you save it.
Agent drafts
With the in-app events scope granted, the agent drafts seasonal events from your own listing and research. They arrive in the review inbox, and applying one creates a provider draft rather than submitting anything. See review and apply proposals.
Common questions
Does applying an event proposal publish it?
No. It can create a draft in App Store Connect through an action you trigger, and even then the content is not submitted and not live.
Inspect the event in its current provider state and review its copy, art and schedule before the next action. A draft being present is useful preparation, but it should not be announced to the team as a reviewed or customer-visible event.
How many events can I run?
Apple sets the limits on how many events an app can have live and in review. Spek does not add limits of its own.
What makes an event brief useful for drafting?
Describe the real experience happening inside the app, its audience, timing and the message you want to communicate. Make sure the event is supported by the product rather than only by marketing copy. Review the name, descriptions, art and schedule as a single package. The documented in-app event workflow concerns Apple's App Store, and its provider requirements still apply. A clear brief helps your team assess a draft without treating a seasonal suggestion as confirmation that the underlying event already exists.
What should I check before an event is submitted?
Check the app, localized copy, event art and schedule, and verify that the in-app experience will be available as described. Read the current provider state and the exact action being requested. Saving or applying a proposal can prepare a provider draft without submitting it or making it live. Coordinate the operational launch with the actual review and publication state so an internal draft date is not confused with the time customers can discover the event on the store.
How should I handle event content for more than one locale?
Review each locale's wording and images with the same care as the main app listing. Dates, terminology and examples can be misunderstood when copied directly between audiences, even if the event itself is shared. Keep the factual event details consistent while making the explanation natural for the selected language. Check the final schedule and provider state separately from the translation review. Approving one localized draft should not be taken as approval of every version prepared for the event.
Does an event proposal change my normal listing metadata?
An event is a separate store object with its own content and lifecycle. Review the proposal and the action's scope to understand whether it prepares event content or changes a listing field. The normal metadata draft and publishing workflow should still be checked independently. If the event relates to a broader release, coordinate the messages across both surfaces, but do not assume accepting one proposal publishes the other. Read the actual provider outcomes before announcing that all parts of the release are live.