App Icons and Screenshots: What the Store Actually Rewards

Most teams spread their design hours evenly across five screenshots, then export the icon as the last step before hitting submit. It feels thorough. It is the wrong allocation. An app icon is the small square image that represents an app in search results, on the listing, and on the home screen after install. The screenshots are the frames beneath it that carry what the app actually does. Both are viewed in a fixed order, and that order is far shorter than the layouts teams build for. The icon is judged first, at thumbnail size, in a row of competitors, before a single word is read. Then screenshot one. Then screenshot two. After that, attention falls off a cliff. By the end of this post you will know the job each slot has to do, and the exact icon and screenshot specifications for both stores, so your design hours land where attention actually is.

The store page has an order of attention, and it is short

The sequence is consistent everywhere you look: the icon, then the first screenshot, then the second, then a steep drop. What is not consistent is how steep the drop is. This is where the published numbers get interesting, because they contradict each other in a way worth sitting with.

Reported figures include roughly 70% of visitors never scrolling past the first screen, only about 9 to 11% viewing the full set of screenshots, and one source putting the share who swipe past the first two at around 40%. That last figure cannot coexist with the first. If only about 30% get past screenshot one, then at most 30% can reach screenshot three, so a 40% swipe-past-the-first-two rate is arithmetically impossible alongside a 70% first-screen drop-off. They are measuring different pages, different placements, or different definitions of a "view," and none of them is telling you your number.

So do not plan against any single figure. Plan against the shape, which every source does agree on: attention is front-loaded, it concentrates on the icon and the first two screenshots, and it thins fast after that. That agreement is the reliable part. The magnitudes are not.

Attention across store page slots shown as shape only with no axis scale, marking three published figures where two of them cannot both be true.

The icon's real constraint

The icon is usually treated as a branding decision, and it is made last. That is the reframe worth making: the icon is the first conversion asset on the page, not the final polish on it. It is the one element judged before any text is read, at a size smaller than anything else you design, sitting in a vertical row of direct competitors doing the same thing.

That changes what the icon has to survive. It has to remain legible when scaled down to a thumbnail in search results. It has to stay distinct in a row of rivals who often share the same category conventions, the same palette, the same visual shorthand. And it is the only asset on the entire store page that follows the user afterward, because it lives on their home screen once they install. Nothing else you design has to work at that size, in that lineup, and then keep working for months on a device you will never see.

Naming that constraint is different from issuing a rule about how to meet it. What makes an icon legible at thumbnail size, or distinct in its category, is a judgment call that depends on the category, the competitors, and the brand. The constraint is fixed. The response to it is not, and it belongs to the team making the call.

The same app icon at three scales: large on a design canvas with its true store size marked in the corner, at thumbnail size in a column of competing apps, and on a home screen after install.

What each screenshot slot carries

The first two screenshots and the last three are not doing the same job, and the difference is not quality. It is position in the attention order. Screenshot one is seen by nearly everyone who reaches the page. Screenshot four is seen by a fraction of that. Whatever a redesign of screenshot four is worth, it is bounded by how few people arrive there. The ceiling on that slot is set by its position, not by its quality.

There is a second constraint on the early frames that the later ones escape: the first screenshots are frequently rendered inside the search results row, before the page is even opened. At that size only the largest line survives. A caption built for the row still reads. The interface text inside the screenshot, the labels and numbers that look fine at full size, collapses into texture. The first frames carry one line, not a layout.

How practitioners respond to this varies, and reasonably so. Some place the highest-legibility caption first because that is where the size penalty is worst. Some treat the first frame as a standalone hook and the rest as elaboration. Some test caption position high versus low against their own audience rather than adopting a convention. These are tradeoffs, not answers. What every approach shares is an acknowledgment that slot one operates under a legibility constraint the later slots do not, and that constraint should inform the call, not dictate it.

An App Store search result showing two apps with their first screenshots rendered inline in the row, with one caption that stays readable at that size and one piece of interface text that does not.

The specifications, both stores

This is the part where judgment ends and facts begin. The values below are the current specifications, formatted for reference rather than reading. Each one was read off the store's own documentation rather than a secondary source, and the date it was checked is at the bottom of this section.

Apple App Store

- App icon: 1024 x 1024 px, flattened, no alpha channel and no transparency. Do not round the corners yourself, Apple applies the mask.

- iPhone screenshots, 6.9 inch: 1320 x 2868 px, or 1290 x  2796 px, or 1260 x 2736 px. Apple accepts all three for this display. Dimensions given portrait; transpose for landscape.

- iPad screenshots, 13 inch: 2064 x 2752 px, or 2048 x 2732 px.

- How many screenshots per set: one to ten, in .jpeg, .jpg or .png.

- How many sets you build: one per device family, not one in total. An iPhone set is required if the app runs on iPhone, at 6.9 inch or at 6.5 inch in its place, and a 13-inch iPad set is required if it runs on iPad, so an app on both ships two sets. Within a family the store scales down for you: Apple's wording is that if screenshots in the accepted sizes are not provided, scaled versions of the larger display's screenshots are used.

That scaling rule answers a question people ask constantly: no, you do not need a separate screenshot template for every screen size. You produce one set at the largest size in each family and the store fills the smaller slots from it. What you cannot skip is the second family. iPhone and iPad are separate requirements, not one requirement with a bigger canvas.

Google Play

- App icon: 512 × 512 px, 32-bit PNG with alpha, maximum 1024 KB.

- Phone screenshots: minimum 2 to publish. JPEG or 24-bit PNG with no alpha. Shortest side at least 320 px, longest side at most 3840 px. Play recommends at least 1080 × 1920 for portrait if you want the screenshots eligible for some of its promotional placements.

- Feature graphic: 1024 × 500 px, JPEG or 24-bit PNG with no alpha. No App Store equivalent.

The thing that trips people up most is transparency, and it is not a difference between the two stores. It is a rule that changes per asset. The App Store icon must be flattened with no alpha channel. The Google Play icon must be a 32-bit PNG that carries alpha. But the Google Play feature graphic and the Play screenshots must not carry alpha at all. So within one store you are asked for alpha on the icon and no alpha on everything beside it, and no single export preset satisfies the set. Apple is also the strictest about it: a file that looks fully opaque but was exported with an alpha channel is rejected, and it is the most common icon rejection on the platform.

Maintenance: every value above was checked against first-party documentation on 11 August 2026, Apple's App Store Connect help and Google Play Console help. Store requirements change, and the fact that Apple currently accepts three different pixel sizes for the same 6.9-inch display is a good indication of how often. Recheck each value at the source in six months.

App icon and screenshot specifications side by side for the App Store and Google Play, verified against each store's own documentation, with the alpha channel rule that changes per asset rather than per store called out.

The ten-minute audit of your own listing

None of the above tells you what to design. It tells you where design decides anything, and you can check your own listing against it without a tool.

1. Open your listing inside the store's search results, not in App Store Connect or the Play Console. That is the size and the context your icon is actually judged in.

2. Put your icon beside the three apps ranking above you for your main term. If you cannot pick yours out at that size in about a second, it is doing less work than you think it is.

3. Read the caption on screenshot one at that same size, in the row, without zooming. If it is not legible there, it is not legible in the moment that decides the tap.

4. Add up how much of your design time went into screenshots three, four and five, and set it against where the order says attention actually is.

None of those four steps tells you what to change. They tell you which slots are carrying weight and which ones are being redesigned on faith. That is a consequence of the attention order, not an instruction about which asset to touch.

Those four steps take ten minutes, and they describe one moment. The row you are measuring yourself against keeps moving. Competitors ship new icons, replace a first screenshot, and run their own tests on the same slots you are looking at, and the slot they choose to change is itself a signal about where the category thinks the leverage is.

Running the check once tells you where you stand today. Running it every time the row changes is the part we built OWA AI to do: it watches the listings you compete with, flags when one of them is testing its icon or its screenshots, and frames the slot that changed between their variants so you can see which one they were actually arguing about.

The audit still belongs to you. The tool only keeps it current.

FAQ

What is an app icon?

An app icon is the small square image that represents an app across the store listing, search results, and the user's home screen after install. It is the first visual element a potential user sees, rendered at thumbnail size in a list alongside competing apps, and it is the only store asset that stays with the user on their device after they install the app.

What size should an iPhone app icon be?

The App Store app icon is supplied at 1024 × 1024 pixels, flattened, with no alpha channel and no transparency. Do not round the corners yourself, Apple applies the mask. You supply that single source and the smaller icon sizes used across iOS are derived from it, so there is no need to export a set of variants. An icon that looks fully opaque but was exported carrying an alpha channel is rejected, which is the most common icon rejection on the platform. Checked against Apple's App Store Connect help, August 2026.

What are the App Store screenshot sizes?

For the 6.9-inch iPhone display Apple accepts 1320 × 2868, 1290 × 2796 or 1260 × 2736 pixels, and for the 13-inch iPad display it accepts 2064 × 2752 or 2048 × 2732 pixels, all given portrait. You upload one to ten screenshots per set. You build one set per device family rather than one in total: an iPhone set is required if the app runs on iPhone, and a separate 13-inch iPad set is required if it also runs on iPad. Within a family the store scales down for you, so a separate template per screen size is not required, but the second device family is not optional. Checked against Apple's App Store Connect help, August 2026.

What size should an Android app icon be, and how does it differ from iOS?

The Google Play app icon is 512 × 512 pixels, supplied as a 32-bit PNG with alpha, under 1024 KB. The App Store icon is 1024 × 1024 pixels and must be flattened with no alpha at all, so a file exported correctly for one store is exported incorrectly for the other. The rule is per asset rather than per store, which is the part that catches people: within Google Play the icon must carry alpha, while the 1024 × 500 feature graphic and the screenshots must not, and both of those are JPEG or 24-bit PNG. The feature graphic has no App Store equivalent. Checked against Google Play Console help, August 2026.

The part of this you actually control

The attention order does not bend to how much work you put into any single slot. Your design hours are the only variable on your side of it, and the audit above settles where they are currently landing in about ten minutes. Where these choices sit inside the store-page funnel, and which of them you can actually prove, is the layer above this one.