App Store screenshots for a shopping app

By Abdalla Kamesh · Published September 21, 2026 · 5 min read

Nobody reads app descriptions. People swipe two or three screenshots and decide. For a store app, where the pitch is “our catalog, in your pocket,” those screenshots are doing all the persuasion.

Here is how to build a set that converts, and how to avoid the one mistake that turns them into a rejection.

What each store requires

Requirements move, so verify on Apple’s and Google’s own pages before you export. What is stable:

Apple wants screenshots per device size class. In practice you need a set at the largest current iPhone size and, if you support tablets, an iPad set. Apple can scale one iPhone set down across sizes, but the largest set is the one people see, so make it the good one. Up to 10 per size class.

Google Play wants a minimum of two phone screenshots (most listings use 4–8), plus a 1024×500 feature graphic, which appears above your screenshots and is the first thing many people see. Tablet screenshots are strongly recommended and required for some placements.

Both want a high-resolution icon: 1024×1024 for Apple (no transparency, no rounded corners — the OS rounds it), 512×512 for Google.

The order that converts

Sequence matters more than polish. Put your strongest frame first, because it is the only one guaranteed to be seen.

1. Your catalog, browsing. A category grid full of your actual products. This is the promise of a store app, stated visually. Do not lead with a login screen, a splash screen, or an empty state.

2. A product page. With the gallery, the price, the variation picker showing real colors or sizes. This is where a shopper imagines using the app.

3. Search or filters. Proof they can find things. For a large catalog this is a genuine selling point.

4. Order tracking. Often the single most-cited reason customers keep a store app. Show an order with a real-looking status.

5. Wishlist or account. The “this remembers me” frame.

6. One brand frame, if you have room. Your lookbook image with a line of copy.

Caption overlays: yes, but restrained

The convention is a short line of text above or below the phone frame. It works, and it works better with limits:

Three to five words. “Shop the full catalog.” “Track every order.”
One line, never two.
Legible at thumbnail size. People see these small first. If you cannot read it in a 200 px preview, it is not doing anything.
A benefit, not a feature. “Reorder in two taps” beats “Native storefront.”

Do not put your entire value proposition in frame one, and do not use the same caption style as a screenshot of a different app you liked — clarity beats trend.

The mistake that gets you rejected

Do not show screens your app does not have.

Both stores treat screenshots as a representation of the app. A composited marketing image showing a feature you have not built, a device frame around a screen that never appears, or a UI mocked up in a design tool that differs materially from the shipped app, is a rejection reason — and a well-earned one, because it misleads the customer.

Practical version: take real screenshots of the real app, then add captions and a device frame if you like. The frame is fine. The fiction is not.

The related trap: showing a promotion. A screenshot with “50% OFF EVERYTHING” locks you into that sale forever, because updating screenshots means editing the listing.

Capturing them properly

Straightforward method, and it takes an hour:

Put good data in the app. Your best products, real photos, a couple of items in the cart, an order in history with a plausible status. Screenshots of an empty app are the most common own-goal here.
Capture at the required device size — a real device of that size, or the simulator/emulator at the right resolution.
Turn off notification clutter. No banners, no low-battery indicator, and a sensible status bar.
Use the same content across frames. Six screenshots of six unrelated products look like six different apps.
Export at exact pixel dimensions. Both stores reject off-size images, and this is the most common upload failure.

Localization, if you need it

If your app ships in more than one language, both stores let you upload per-locale screenshots. For a right-to-left language this is not optional cosmetics: an Arabic listing showing left-to-right screenshots tells an Arabic-speaking shopper the app was not built for them. Capture the RTL set from the app in that language, with mirrored layouts and localized numerals as they actually render. Arabic-first commerce covers what that involves.

The rest of the listing, briefly

Since you are in there anyway:

App name (30 chars): your brand, plus one word if it fits. “Trailhead Goods” beats “Trailhead Goods — Shop Outdoor Gear Online.”
Subtitle (Apple, 30) / short description (Google, 80): the benefit line.
Apple’s keyword field (100 chars): invisible to users, comma-separated, and do not repeat words already in your app name.
Google’s description: indexed for search, so it needs to read well and contain the words people type. There is no separate keyword field.
Privacy policy URL and support URL: both required, both must resolve.

More on the whole submission in publishing your store app.

A checklist before you upload

Real screenshots of the real app
Catalog frame first
Populated with good products and a plausible order
Captions under five words, legible at thumbnail size
No promotional pricing baked in
Exact pixel dimensions per store
Feature graphic done for Google
Icon with no transparency and no pre-rounded corners
RTL set captured separately, if you localize

Related reading

Exact size and count requirements are set by Apple and Google and change — check their current specifications before exporting.