This is an end-to-end process for producing a screenshot set that is ready to upload, written for developers who would rather not become designers just to ship a release.
Step 1: Decide the story before opening any tool
Ten screenshots is not ten features. It is a sequence, and only the first two or three are seen by most people. A structure that works for most apps:
- Screen 1 — the core promise. The one sentence that would make someone install.
- Screen 2 — the strongest proof. The feature that best supports that promise.
- Screens 3 to 5 — supporting capabilities, strongest first.
- Screen 6 onward — depth for the minority who are genuinely comparing options.
Write all the captions before designing anything. Copy constrains layout far more than layout constrains copy, and discovering that your headline is twice as long as the space after designing five screens means redoing five screens.
Step 2: Capture clean source screens
The quality ceiling for the whole set is set here.
- Use the simulator or emulator, not a physical device. You get exact pixel dimensions and a clean status bar.
- Set up realistic content. Empty states and "Test User 1" make an app look unfinished. Populate plausible data.
- Fix the status bar. On iOS the simulator can be set to a clean 9:41 with full signal and battery; on Android, use demo mode.
- Capture at the largest device size you will need — 6.9 inch iPhone, or a 1080 x 1920 Android phone.
- Turn off anything transient: banners, tooltips, debug overlays, notification badges you do not want immortalised.
Capture more screens than you need. Choosing later from twelve candidates is far easier than going back for one more.
Step 3: Choose a layout pattern
Three patterns cover almost every effective listing:
- Headline above, device below. The default for good reason: the caption is read first, and the device is cropped at the bottom edge so it reads as continuing past the frame.
- Full-bleed screenshot. No frame at all. Works when the UI itself is the selling point.
- Angled or paired devices. Useful for showing two states at once, but it costs legibility — use sparingly, and never for screen 1.
Pick one pattern and hold it across the whole set. Mixing patterns makes one listing look like several apps.
Step 4: Set the background and type
- Background: a solid colour or a gentle two-stop gradient drawn from your app's palette. Busy backgrounds compete with the UI you are trying to show. - Headline type: one family, bold weight, large. Somewhere around 90 to 120 px on a 1320 x 2868 canvas is a reasonable starting point. - Contrast: dark on light, or light on dark. Anything in between fails at thumbnail size. - Kicker: a small uppercase label above the headline adds structure without adding reading time.
Step 5: Respect the safe areas
Store thumbnails get cropped and rounded in various placements. Keep all text within the middle 85 percent of the canvas, and nothing meaningful within about 6 percent of any edge. If a device frame is cropped at the bottom, crop it decisively — a thin sliver of frame near the edge reads as a mistake rather than a choice.
Step 6: Export every required size
The set you need depends on the platforms you support. At minimum:
- App Store: 6.9 inch iPhone (1320 x 2868). Add 6.5 inch if you want crisper rendering there, and the 13 inch iPad set (2064 x 2752) if the app supports iPad.
- Play: phone screenshots at 1080 x 1920 or larger, plus the mandatory 1024 x 500 feature graphic. Add 7 inch and 10 inch tablet sets if you support tablets.
Export as PNG without an alpha channel; Apple rejects screenshots containing transparency.
Step 7: Check before uploading
- Open the two thumbnails that will appear in search and confirm the headlines are readable at that size. - Confirm every image matches its required dimensions exactly. - Confirm no alpha channel. - Read every caption once more for typos. A typo in screenshot 1 is seen by everyone. - View the set on an actual phone, not only on your monitor.
Step 8: Make the next release cheap
Screenshot work feels endless because the second release repeats the first. Two habits prevent that:
- Keep text separate from the captured image. Then a copy change is an edit, not a re-capture.
- Keep the source project, not just the exported PNGs, so a device size added next year is a re-export rather than a rebuild.
This is the specific problem MoonStart was built for — one design, every required size, re-exportable when the spec changes — but the principle holds whatever tool you use.