How to make App Store screenshots in 2026

Most guides on this treat it as a design task. It is four tasks, and design is the third one. Skip the first and no amount of design saves you; skip the fourth and you will never know whether it worked.

Here is the whole thing, in the order it actually has to happen.

1. Capture source frames worth designing around

Everything downstream is limited by what you capture. The most common failure in this entire process is not a bad layout — it is a beautiful layout wrapped around a screenshot of an empty app.

Seed believable data first. A task app with three tasks, a finance app with one transaction, a photo app with a grey placeholder grid: these tell a browsing user that nobody uses your product. Fill it with content that looks like a real account in month three.

Then standardise the frame. Pick one status bar state and hold it across every panel:

xcrun simctl status_bar booted override \
  --time "9:41" --dataNetwork wifi --wifiBars 3 \
  --cellularBars 4 --batteryState charged --batteryLevel 100

Then capture at the right device size. An iPhone 16 Pro capture is 1206 × 2622; an iPhone 16 Pro Max is 1290 × 2796. Both are valid App Store sizes, for different display classes. Capturing on the wrong simulator means either upscaling later, which looks soft, or a rejected upload.

Full detail in getting a clean status bar.

2. Decide what the first panel promises

Before any design happens, answer one question: what outcome does this app give someone, in words they would use?

That answer is your first panel. Not your logo, not a welcome screen, not your cleverest feature. Everyone who reaches your listing sees panel one; only a minority swipe past panel two. The set is not an even sequence of eight — it is one panel doing most of the work and seven supporting it.

A useful order for the rest:

1. The promise. The outcome, stated plainly.
2. The proof. Real UI doing the thing, so the promise is credible.
3. The differentiator. The reason to pick you over the obvious alternative.
4. Depth. Secondary features, for people already interested.
5. The nudge. Whatever removes the last hesitation — privacy, offline, no account needed.

Three strong panels beat eight weak ones. The limits — ten on the App Store, eight on Google Play — are ceilings, not targets.

3. Design the set

This is where most tools and most guides start, and where the interesting failure lives.

The default output of any screenshot pipeline is a phone floating centred on a pale gradient with a headline above it, three times in a row. It is clean, it is competent, and it is what you get when you accept the first result. It is also what a large fraction of the store already looks like, which means it reads as generic rather than as bad — a worse problem, because nothing looks wrong.

Four things separate a set that looks designed:

• Vary the composition. If every panel is a centred upright device, the set has one idea. Tilt, crop into the screen, run a device off the edge, let two panels share a continuous background.
• Make the panels share lighting and palette. The reliable way is to design or render them together rather than one at a time and hope they match. Ours are rendered as one wide image and then cut, so they match by construction.
• Keep caption size consistent. One headline wrapping to three lines while another sits on one is the clearest amateur tell in the category, and it is entirely avoidable.
• Never redraw the UI. Style the space around the screen; reproduce the screen exactly. A screenshot showing a button your app does not have is a rejection risk and a refund request.

Whether you do this in Figma, in a template tool, or here matters less than whether the result has those four properties. We wrote about why we build art directions instead of templates, but a carefully made template set beats a careless generated one.

4. Export at exact sizes

App Store Connect compares the exact pixel width and height against its accepted list. Not aspect ratio, not a tolerance band. 1280 × 2768 is refused where 1284 × 2778 is accepted.

Device	Pixels	Apple display type	Max per listing
iPhone	1260 × 2736	APP_IPHONE_67	10
iPad	2064 × 2752	APP_IPAD_PRO_3GEN_129	10

In practice you need a 6.9-inch iPhone set, plus a 13-inch iPad set if your app supports iPad. Apple derives the smaller classes. The complete size list is longer if you want it.

Two rules that cause most rejections:

1. Every screenshot within a display class must be the same size.
2. Resize with a cover fit as the final operation. A "fit within" mode undershoots an axis and rounds you into a near-miss.

If you are already staring at the error, there is a whole post on finding the file that is four pixels off.

Shipping to Android too? The rules are different enough to catch you out — Play caps aspect ratio at 2:1 and requires a 1024 × 500 feature graphic that most listings waste.

5. Find out whether it worked

Everything above is a prior. The only referee is traffic.

Apple's Product Page Optimization runs a variant against your live page. Google's Store Listing Experiments do the same on Play. Both report confidence, and both will show you an early lead that evaporates — let them reach their own threshold before acting.

Test the first screenshot first. Largest sample, largest effect. Then the second panel, then caption angle, then order. Change one thing at a time, or you will learn that something worked and nothing about what.

More on that in product page optimization.

The short version

Seed real data before you capture. Decide what panel one promises before you design anything. Vary the composition and render the set together. Resize to exact pixels as the last operation. Then test it, because your opinion about your own screenshots is the least reliable input available.