Photography Inside App Store Screenshots

The first two panels carry the listing

Store listings show a horizontally scrollable strip of screenshots, and on a phone that means roughly one and a bit panels are visible without any interaction. A visitor who is deciding whether to install will read the first panel, glance at the second, and either tap install, scroll to the description, or leave. Panels four through ten exist for the minority who swipe.

So the first panel is not an introduction to a sequence — it is a standalone answer to 'what is this and why would I want it'. The second panel gets the strongest secondary reason. Everything after that is supporting material for the interested minority, and it is fine for it to be more detailed and less punchy.

The corollary is that teams routinely misallocate effort. The elaborate feature walkthrough in panels five to eight is where the design hours went, and it is the part almost nobody saw. Build the first two properly, then the rest.

Real photography instead of a flat gradient

A device frame floating on a purple gradient is the default look, and it says nothing. Photography behind the frame does two jobs at once: it establishes context — where and why this app gets used — and it makes your listing visually distinct in a strip of competitors who all reached for the same gradient.

The context is the valuable part. A cycling app over a photo of a wet road at dawn, an inventory app over a shot of a real stockroom, a recipe app over an actual kitchen counter tells a story the interface alone cannot. It also quietly qualifies the audience: someone who recognises that stockroom knows the app is for them.

The technical constraint is that the photo must not compete with the screen. It needs to be quiet where the device sits, low in contrast, and out of focus or plain in the areas where the caption goes. This is where a lot of otherwise good photos fail — a busy background makes the interface unreadable. Darkening and softening a region of a photo you already have so the device and the copy stay legible is a small edit; Flora will do that to an existing shot, though it cannot invent the stockroom you never photographed.

Consistency across the set is what makes it look designed

The single most common tell of an amateur listing is that each panel looks like it was made on a different day. Different background colour, different caption size, different device angle, different photographic style. The set reads as a pile rather than a sequence.

Pick a small number of decisions and apply them across every panel: one caption position, one type size, one device treatment, one colour temperature and brightness range for all photography. If panel one uses a warm, low-contrast photo, panel four should not use a cold, punchy one. This matters more than any individual panel being brilliant.

A related discipline is captions. They should be short enough to read while scrolling — a few words, not a sentence — and they should be parallel in construction across the set. Mixed grammatical forms across captions is a small thing that makes a set feel unconsidered.

• One caption position and one type size across all panels
• One consistent device frame treatment and angle
• Photography that shares a colour temperature and contrast range
• Captions of similar length and grammatical form
• A visual system that still holds when panels are seen out of order

Honesty about what the app actually does

Store screenshots are marketing material, but they are also, functionally, a claim about the software. Showing a screen that does not exist, data volumes the app cannot handle, or a feature that is planned rather than shipped is a straightforward way to earn one-star reviews from people who installed on the strength of it — and store review teams take a dim view of it too.

The grey areas are worth naming. Populating the app with pleasant sample data is normal and fine. Showing an idealised empty state that nobody ever sees is misleading. Composing a panel so an interface looks less cluttered than it really is sits somewhere in between, and the test is whether a new user would feel tricked on first launch.

If your app involves anything regulated — health, finance, children, claims about results — assume the rules for what you may show and say vary by jurisdiction and by store, and that they change. Check the current store review guidelines and, where the claims are substantive, take proper advice rather than guessing.

Localisation and the version you will forget to update

If you ship in more than one language, screenshots with baked-in English captions are a problem you will discover late. Building the panels so the caption is a separate text layer over a reusable photographic background makes localisation an afternoon rather than a rebuild.

The same structure helps with the other slow leak: screenshots that show an interface two redesigns old. A listing whose panels do not match the app people install is a small credibility cost every time. Keeping the source files organised and the background photography separate from the interface captures means updating after a redesign is mechanical.

Set yourself a rule that any release changing the main screens triggers a screenshot refresh of at least the first two panels. Those are the ones that matter, and refreshing two is achievable in a way that refreshing ten is not.

Check the current requirements at build time

Both major stores publish required screenshot dimensions, device size classes, file formats and quantity limits, and these change whenever new hardware ships or the store console is revised. A dimension list from any article, including this one, is a snapshot with a short shelf life.

The practical habit is to open the current developer documentation for each store the week you build the assets, and to re-check whenever a submission gets rejected on asset grounds. There are usually also rules about what may appear inside a screenshot — pricing claims, references to other platforms, awards, promotional badges — and those are enforced inconsistently enough that reading the current text is genuinely worthwhile.

Design the master panel at the largest required size and derive the smaller ones from it, keeping the essential content away from the edges so that different device aspect ratios do not clip your caption.

Frequently asked