App Store In-App Events and Google Play Promotional Content: A 2026 Guide to Getting Featured

What In-App Events and Promotional Content Actually Are

App Store In-App Events and Google Play's Promotional Content (the modern version of what used to be a single feature graphic slot) are scheduled, time-boxed listings that both platforms surface in search results, browse tabs, and editorial collections. They exist to answer a question static screenshots can't: "What's happening in this app right now?" A double XP weekend, a new season drop, a live shopping event, a limited-time discount. Done well, they are one of the few remaining organic ways to get featured placement without paying for it or waiting for an editor to notice you.

Both stores treat these slots as a ranking and discovery signal, not just decoration. Apple has said publicly that apps running In-App Events see measurable lifts in both impressions and downloads during the event window, and Google's Play Console explicitly ties Promotional Content performance to where and how often it gets surfaced. If you're only updating your screenshots twice a year, you're leaving a recurring, free distribution channel on the table.

App Store In-App Events: The Mechanics

An In-App Event on the App Store is built from a title, a short and long description, a deep link, a start and end date, and one piece of media. That media requirement is where most submissions fail, because Apple enforces it strictly:

The event card image or video (the one shown in search and browse) must be 16:9 landscape, minimum 1920x1080px up to 3840x2160px, in .jpg, .jpeg, or .png for stills, or .mov/.m4v/.mp4 for video at 30 or 60fps. The event details page asset, shown when someone taps into the event, flips to 9:16 portrait at the same resolution range. Video audio needs to be stereo AAC at 256kbps. Every asset caps out at 500MB, but the far more common rejection reason isn't file size, it's submitting a square or 4:5 asset that was clearly recycled from a social ad rather than built for the actual aspect ratio Apple asks for.

Apple allows up to 10 events live per app, but only recommends running events that map to something a user can actually do in the next few days: a live tournament, a content drop, a seasonal sale, a challenge with a deadline. Evergreen "check out our app" events get rejected or simply ignored by the algorithm, because there's no urgency for the system to reward.

Google Play Promotional Content: What Changed

Google Play's equivalent has quietly expanded past the old single 1024x500px feature graphic. That banner size is still required as your baseline store listing asset (JPEG or 24-bit PNG, no alpha channel, no transparency), but Promotional Content now lets you attach time-boxed events, offers, and announcements that surface in the Play Store's "Offers" and "Events" carousels, similar in spirit to Apple's system. Google's own guidance is blunt about crop safety: keep your core message and logo centered, because Play surfaces will crop edges or lay UI chrome over the banner depending on where it's shown (search results, the Games tab, a personalized recommendation card).

The practical overlap with Apple's system: both platforms want short-lived, dated, specific content, both reward developers who treat this as a recurring calendar item rather than a one-off submission, and both will quietly stop showing your content the moment it expires if you haven't queued up the next one.

A Submission Calendar That Actually Works

The developers who get consistent featuring treat In-App Events and Promotional Content like a content calendar, not a one-time setup task. A workable cadence for 2026 looks like this: submit new event assets at least 7 to 10 days before a live date to clear Apple's human review queue with buffer room, never let a live event lapse without a successor already in the review pipeline, and reuse a repeatable visual template (same logo placement, same type treatment, same color system) so each new event takes minutes to produce rather than a fresh design cycle every time.

That last point is the actual bottleneck for most indie developers and small marketing teams. The creative isn't hard conceptually, it's a 16:9 landscape image with a headline, a countdown-worthy hook, and your app's branding, but producing a correctly-sized, on-brand version of it every two weeks is exactly the kind of repetitive design work that gets skipped when there's no designer on staff. This is squarely where a template-based creative tool earns its keep: WhixFrame's Ad Creatives generator and Screenshot Studio can output the 16:9 event card and 9:16 details page assets straight to Apple's exact resolutions, using the same branding and layout system across every event so you're not rebuilding the design from scratch each time you have news to announce.

What to Actually Put in the Event

Apple and Google both reward specificity over vague hype. Compare "Big Update!" against "Season 4 Launches Friday: New Maps, New Rewards." The second version gives the algorithm a concrete, dated claim to match against actual user behavior (did engagement spike on Friday?), which is part of how these systems decide whether to keep surfacing your event to more users. Concrete event types that consistently perform:

Limited-time content drops (new levels, seasons, collections). Live or scheduled competitions and tournaments with a visible leaderboard. Time-boxed discounts or bundle offers with a real expiration, not a fake one that resets every week. Community or social features tied to a specific date (a livestream, a group challenge, a launch party). Major version updates framed as an event rather than a changelog entry.

Avoid submitting an event for something with no real end date. Both platforms' review teams and algorithms are tuned to spot recycled "always on" content dressed up as time-limited, and repeated submissions like that tend to get deprioritized in how often the system chooses to surface future events from your app.

Measuring Whether It's Working

App Store Connect breaks out impressions, page views, and conversion specifically for the event window versus your baseline listing performance, so there's no guesswork needed. Play Console reports similarly on Promotional Content reach. The benchmark worth tracking isn't absolute downloads, it's the delta: does your conversion rate during an active event beat your 30-day baseline? If an event type doesn't move that number after two or three attempts, drop it and try a different angle rather than assuming the format itself doesn't work. Developers who've been running these regularly for a few cycles typically see event windows outperform baseline conversion by a meaningful margin, largely because urgency and specificity are two of the strongest conversion levers a store listing has access to, and static screenshots can't create either one.

Making It Sustainable

The single biggest reason developers stop running In-App Events after a promising first try is production overhead, not lack of results. If every event needs a designer's time to build a correctly-sized, on-brand card image, it quietly becomes a "when we have time" task and the calendar goes cold. Treating the visual asset as a template you refresh with new copy and a new date, rather than a bespoke design project every time, is what turns this from a one-off experiment into a recurring growth channel. Whether you build that template system in-house or generate it through a tool built for exactly these dimensions, the goal is the same: make the next event take 10 minutes, not two days, so you actually keep the calendar running through Q4 and into next year.