Fix "The dimensions of one or more screenshots are wrong"

You uploaded ten screenshots. App Store Connect took nine and threw this at the tenth:

The dimensions of one or more screenshots are wrong.

It does not say which file. It does not say what it wanted. And the image looks completely fine, because it is off by four pixels.

What App Store Connect is actually checking

It compares the exact pixel width and height of the file against the list of sizes it accepts for the display class you are uploading to. Not the aspect ratio, not "close enough", not a tolerance band. 1280 × 2768 is not a slightly small 1284 × 2778 — it is an unrecognised size, and it is refused.

That distinction matters because most of the ways a screenshot gets resized will happily hand you a near-miss:

• Image models return an approximation of what you asked for. We log this constantly in our own render pipeline: ask for 1284 × 2778 and you get 1280 × 2768 back. Every generated panel goes through a deterministic resize afterwards for exactly this reason.
• "Fit within" resize modes preserve aspect ratio and undershoot one axis. A 19.5:9 source fitted into a 19.5:9 box lands a pixel or two short after rounding.
• Screenshots from the wrong simulator. 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. Mixed into one set, one of them is wrong.
• Anything that opened in an editor and got exported. Export dialogs round.

Find the offending file in one command

You do not need to open anything. On macOS:

# every PNG in the folder, with its real pixel dimensions
sips -g pixelWidth -g pixelHeight *.png

# or, grouped — anything that is not the majority size is your problem
magick identify -format "%w x %h  %f\n" *.png | sort | uniq -c | sort -rn

The second one is the useful one. A healthy set prints a single row. A broken set prints your answer on line two.

The sizes Apple accepts

These are the dimensions our exporter renders against, straight from the preset registry it uses — so this table cannot drift from what actually ships.

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

Every other accepted size (21)

Device	Pixels	Apple display type	Max per listing
iPhone	1290 × 2796	APP_IPHONE_67	10
iPhone	1320 × 2868	APP_IPHONE_67	10
iPhone	1284 × 2778	APP_IPHONE_65	10
iPhone	1242 × 2688	APP_IPHONE_65	10
iPhone	1179 × 2556	APP_IPHONE_61	10
iPhone	1206 × 2622	APP_IPHONE_61	10
iPhone	1170 × 2532	APP_IPHONE_61	10
iPhone	1125 × 2436	APP_IPHONE_61	10
iPhone	1080 × 2340	APP_IPHONE_61	10
iPhone	1242 × 2208	APP_IPHONE_55	10
iPhone	750 × 1334	APP_IPHONE_47	10
iPhone	640 × 1136	APP_IPHONE_40	10
iPhone	640 × 960	APP_IPHONE_35	10
iPad	2048 × 2732	APP_IPAD_PRO_3GEN_129	10
iPad	1488 × 2266	APP_IPAD_PRO_3GEN_11	10
iPad	1668 × 2420	APP_IPAD_PRO_3GEN_11	10
iPad	1668 × 2388	APP_IPAD_PRO_3GEN_11	10
iPad	1640 × 2360	APP_IPAD_PRO_3GEN_11	10
iPad	1668 × 2224	APP_IPAD_105	10
iPad	1536 × 2048	APP_IPAD_97	10
iPad	768 × 1024	APP_IPAD_97	10

You do not need all of them. Apple derives smaller sizes from larger ones, so in practice a current listing needs 6.9-inch iPhone, plus 13-inch iPad if your app supports iPad. Uploading the full matrix is harmless and removes a class of support question, but it is not required.

Fixing it properly

The fix is a resize to the exact target, not a nudge:

1. Identify the display class you are uploading to, and pick one size from the table above. Do not mix sizes within a class.
2. Resize with cover, not fit — fit will undershoot an axis and put you back where you started.
3. Re-check with the identify command before you upload again.

With sharp, that is:

await sharp(input)
  .resize(1290, 2796, { fit: 'cover', position: 'centre' })
  .png()
  .toFile(output);

fit: 'cover' guarantees the output is exactly the dimensions you named. It will crop a sliver if the aspect ratio differs, which is the correct trade — a two-pixel crop nobody can see beats a rejected upload.

Why this keeps happening

Because the requirement is a pixel count and almost every tool in the chain thinks in ratios. The only durable fix is to make the exact size the last operation before the file is written — never an intermediate step, never something an export dialog gets a vote on.

That is how our renderer works: whatever the model, the canvas or the device frame produced, the final write is a deterministic resize to a size from the registry. There is no path through it that can emit 1280 × 2768.