App Store Connect Won’t Accept Your Screenshots? Every Reason It Happens

The build is uploaded. The description is written. You have been staring at App Store Connect for forty minutes and it still will not take your screenshots, and the message it keeps giving you does not say which of the eight files is the problem.

Almost every screenshot upload failure comes down to one of a small number of causes, and none of them are interesting. They are pixel counts, the wrong tab, and a missing iPad set. Here is each one, how to recognise it, and what to change.

What App Store Connect actually checks when you drop a file in

The upload check is mechanical and shallow. It looks at the pixel dimensions, the file format, the colour space, and whether the slot you dropped it into expects those dimensions. Nothing about your design, your captions or your claims is examined at this stage.

That tells you where to look. If the file will not upload at all, it is a technical problem with the file. If it uploads fine and the app is rejected a few days later, it is a content problem, and that is a separate section further down. Worth knowing either way: Apple does not resize anything for you. It compares your file against a list of accepted sizes and refuses anything that is not on it.

The sizes Apple currently accepts

These are the dimensions to aim at. Apple does revise this list, so treat it as a strong starting point and glance at the current requirements in App Store Connect before a big submission.

The useful shortcut here is that the 6.9-inch set covers the whole current iPhone range. Upload it once and Apple scales it down for the smaller displays in search results and on the product page. You do not need to produce four iPhone sets any more, and I would not bother with the 6.5-inch and 5.5-inch sizes unless you have a specific reason to control how the listing looks on older hardware.

If you want the full table including the Google Play sizes, there is a longer reference on the App Store screenshot sizes page.

Reason 1: the dimensions are off by a few pixels

This is the big one, and it is almost always something in the middle of your workflow quietly resizing the file: a design tool exporting at a rounded-off size, a screenshot from a device with a different logical resolution than you assumed, an image sent through a messaging app, or a “compress before upload” step that also scaled it down by a percent or two.

Check the actual file rather than the export settings. On a Mac, select it and press space to see the dimensions in the preview. On Windows, right-click, choose Properties, and open the Details tab. You want 1290 × 2796 and nothing else.

If the number is wrong, resizing the existing image is usually the wrong fix. Scaling a 1284-wide screenshot up to 1290 makes it slightly soft, and the next person to look at it will notice before they can say why. Re-export at the right size, or rebuild the set with something that draws at the target dimensions directly.

Reason 2: the file is fine, the tab is wrong

App Store Connect has a separate upload area for each display size. If you are on the iPad tab and you drag in a 1290 × 2796 iPhone image, it refuses it, and the message does not say “you are on the wrong tab”.

This catches people constantly, particularly when the folder of exports is flat and every file is called something like screenshot-1.png. The fix is organisational rather than technical: name your exports with their dimensions in the file name, or keep each set in its own folder. If your files are called 01-1290x2796.png you will never drop one in the wrong place.

Reason 3: your app supports iPad and you have not made iPad screenshots

This one does not look like a screenshot error at all. The upload works, the iPhone images sit there happily, and then the submit button refuses to do anything useful.

If your app’s target includes iPad, App Store Connect requires an iPad screenshot set before the version can be submitted. It will not reuse your iPhone images, however good they are.

Two ways out: produce a proper iPad set at 2064 × 2752, or make the app iPhone-only if iPad support was never intentional. The second happens more than you would think, usually because a universal target was left on by default. If you are doing it properly, capture on an actual iPad or simulator. An iPhone screenshot stretched into an iPad frame looks wrong in a way reviewers notice, and so do customers. There is a walkthrough on the iPad screenshot generator page.

Reason 4: transparency, and the myth that goes with it

There is a widely repeated piece of advice that App Store screenshots must not have an alpha channel. It is close to the truth but not quite right, and the imprecision sends people chasing the wrong fix.

The actual problem is a transparent region in the image. A PNG saved from a browser canvas or most design tools is technically RGBA, which means it carries an alpha channel, but if every pixel in it is fully opaque there is nothing to complain about. Our own exports are RGBA and fully opaque, and they upload without argument.

Where it goes wrong is when part of your design genuinely has nothing behind it. A device frame floating on an empty background, a logo exported with a cut-out, a layer you hid rather than deleted. Those leave real transparent pixels, and that is what gets refused.

The fix is to flatten onto a solid background before you export: a filled rectangle at the bottom of the layer stack covering the whole canvas, or export as JPEG, which has no concept of transparency at all. Both stores accept JPEG for screenshots.

Colour space is a related and much rarer issue. Apple wants RGB. This almost never happens to people working from phone screenshots, and almost always happens to people whose designer sent over an asset from a print workflow in CMYK.

Reason 5: format and file size

PNG or JPEG. That is the whole list. Not WebP, not HEIC, not PDF, not a screenshot you renamed from .heic to .png without actually converting it.

That last one deserves a note, because recent iPhones save photos and some screenshots in HEIC, and renaming the extension does not change the file. If your file is secretly HEIC, convert it properly with a HEIC to JPG converter rather than renaming it.

File size is rarely the blocker for screenshots the way it is for app binaries, but very large PNGs can time out on a slow connection and look like a rejection when they are really a failed upload. If a single screenshot is coming in at 15 MB or more, something upstream is wrong. Our 1290 × 2796 exports land around 2 MB. If you genuinely need to get one smaller, the Image Resizer can hit a target size, and there is a longer guide on resizing an image to a specific file size.

Reason 6: too few, or too many

Apple needs at least one screenshot per display size you support, and takes up to ten. Google Play needs at least two phone screenshots to publish at all, and at least four before your listing is eligible for promotional placement anywhere on the store.

Ten is the ceiling, not a target. Only the first three show in App Store search results, which is the context where most people make the decision. Everything after the third is seen by people who have already swiped, and who are therefore already interested. Three strong screenshots beat ten mediocre ones, comfortably.

Reason 7: it uploaded fine and the app was rejected anyway

Everything above happens at upload. This happens days later, during review, and it is a completely different category of problem. A human looked at your screenshots and did not like what was on them.

The recurring causes:

• Ratings or awards you do not have. Five gold stars drawn into the image, a “#1 app” banner, an editorial badge you were never given. Both stores reject these.
• Mentions of other platforms. “Also on Android” in an App Store screenshot is a reliable rejection, and the reverse is equally true on Google Play.
• Prices or offers that are not real, or that do not match your in-app purchase configuration.
• No actual app in the screenshots. A set made entirely of marketing title cards, with no interface visible anywhere, does get bounced. Apple expects the images to represent the real in-app experience.
• Features your app does not have yet. Showing a screen from the version you are planning is a quick way to lose a week.

The common thread is that screenshots are treated as claims about the product, not as decoration. If an image implies something that is not true of the build you submitted, expect it to come back.

Getting it right the first time

Most of this is avoidable by changing where the images come from rather than how you fix them afterwards. Capture on a real device or simulator at native resolution, do not run the files through anything that resizes or recompresses, and build the final store images at the exact target dimensions instead of designing at some arbitrary size and scaling at the end.

That last point is the one people skip. If you design at 1080 × 2340 because that is what your phone produces, then scale to 1290 × 2796 for Apple, you have softened every edge and every letter for no reason. Build at the target size and the text stays crisp.

Our App Store Screenshot Generator works that way: you supply the raw screenshots, and each output image is drawn at its destination size rather than scaled into it. The zip arrives sorted into App Store/iPhone 6.9-inch/, App Store/iPad 13-inch/, Google Play/Phone/ and so on, with the pixel dimensions in every file name, which also solves the wrong-tab problem.

A checklist before you upload

• Open each file and confirm the real pixel dimensions, rather than trusting the export dialog.
• Check there are no transparent areas. Flatten onto a solid background, or export JPEG.
• Confirm the files are genuinely PNG or JPEG, not renamed HEIC.
• Make sure the iPad set exists if your app targets iPad.
• Match each folder to the right display size tab in App Store Connect.
• Read your own captions as a reviewer would. No invented ratings, no other platforms, no features you have not shipped.
• Check that the first three images make sense on their own, because those are the ones most people see.

Work through that list and the upload step stops being an event. It becomes the boring thirty seconds it should always have been, and you can go back to worrying about the parts of launch that actually deserve the anxiety.