iPad App Store Screenshots, Not Scaled iPhone

iPad App Store screenshots are pictures of the iPad app. If the binary supports iPad, Apple requires the 13-inch set. The usual shortcut, dropping an iPhone screenshot onto a large canvas and scaling it, fails for a layout reason, not only a pixel reason. A phone UI is a column. An iPad UI has room for a sidebar, a canvas, and sometimes a second pane. Stretching the column does not create those.

The pixel table, including 2064×2752 for the 13-inch slot, is in App Store screenshot sizes. This page does not repeat that table. It is about what to put inside the file. Frames, if you use them, still have to leave the UI readable, which device frames covers. Capture steps are in how to make the screenshots.

Support for iPad means the slot is required

If the app runs on iPad, the listing needs iPad screenshots. “It is mostly an iPhone app” is not a waiver. Shoppers on iPad see the iPad gallery. An empty iPad slot, or a phone image pretending to be one, is what they judge. Check the binary’s device support before you decide you can skip the set.

You still get one screenshot set per device size per localization. The iPhone set and the iPad set are different slots. They can tell the same story. They cannot be the same file scaled. Uploading the iPhone PNG into the iPad well either fails the dimension check or, if you padded it, shows a phone floating in a field of background.

Shoot the layout the tablet actually uses

Open the app on an iPad simulator or device at the size you must export. Look at the first screen a new user gets in full-screen. Note where navigation lives. On iPad that is often a sidebar, a top bar with more room, or a split view with a list and a detail. Screenshot that. Do not screenshot the iPhone simulator and hope a background color will hide the difference.

Split view is part of the platform, but the store shot should show the layout you designed for the full window, unless your app’s main case is living beside another app. A screenshot of a squashed split view you did not design looks like a bug. A screenshot of the full iPad window shows the sidebar and the canvas the way you intend people to work.

Worked example: a drawing app with a sidebar

The app is a drawing tool. On iPhone the tools are a bottom shelf and the canvas is the whole screen. On iPad the tools live in a sidebar, the canvas sits in the remaining width, and a layers panel can open on the trailing side. That sidebar is the product difference. If the iPad screenshot is a scaled phone, the sidebar never appears, and the listing sells the phone app to tablet buyers.

Frame one on iPad shows the canvas with the sidebar open and a simple drawing in progress, not a finished poster you pasted in. Frame two shows the brush size where the finger actually changes it, in the sidebar, so the control is visible. Frame three shows layers, because that is why someone wants the bigger screen. The caption stays short. The sidebar has to remain readable when the file is previewed smaller than 2064 pixels wide.

The iPad screenshot has to show the sidebar and canvas together. Scaling the iPhone shelf-and-canvas layout does not produce that screen.

Leave the sidebar readable

iPad files are large, and people still meet them in a smaller preview. A sidebar full of 12 tiny tool icons becomes mush. For the store, open the sidebar in a state with fewer, larger tools, or a state where the active tool is obvious. You are not documenting every brush. You are showing that the iPad app has a real tool column.

Captions should sit in a band that does not cover the sidebar or the drawing hand. Screenshot best practices apply here: one idea, type that survives a shrink. A caption stretched across a tablet in a thin weight will fail even when the layout is correct.

Frames and orientation are layout choices

If you add a device outline, use an iPad outline around an iPad capture, inside the required pixel size. An iPhone bezel centered on the 13-inch canvas is the scaled-phone mistake with extra steps. Many drawing apps are more honest in a wide layout because the sidebar and canvas sit side by side. Export the orientation the slot allows and the app actually uses. Do not rotate a portrait phone shot and call it a tablet.

Right-to-left languages move the sidebar to the other side. If you localize into Arabic or Hebrew, mirror the iPad UI. Do not keep a left sidebar from the English capture and only translate the caption. That is the same class of error as scaling, just in the other direction.

Same story, different composition

The iPhone set and the iPad set can share a promise: draw, change the brush, use layers. The composition should not be shared. On the phone, the brush tool is a sheet. On the tablet, it is the sidebar. Write captions that fit each composition. “Tools beside the canvas” is an iPad line. It is a lie on the phone set.

AppGrowthKit matters when you are producing both sets from real captures and need the iPad file at 2064×2752 without someone resizing the phone export at the last minute. Keep the phone project and the tablet project separate so a one-click scale cannot sneak back in.