The Short Answer
Almost every screenshot upload failure comes down to three things: the pixel dimensions don't match an accepted class, the PNG has an alpha channel, or the colour profile isn't sRGB.
The error messages App Store Connect returns are unhelpfully generic, which is why people spend an hour re-exporting the same broken file.
Quick reference: the 6.9-inch iPhone class accepts 1320 x 2868, 1290 x 2796 and 1260 x 2736 in portrait. Files must be PNG or JPEG in sRGB with no transparency. Get those three right and the upload goes through.
Below are the specific errors, what each one actually means, and the export settings that make the problem go away permanently.
The error messages App Store Connect returns are unhelpfully generic, which is why people spend an hour re-exporting the same broken file.
Quick reference: the 6.9-inch iPhone class accepts 1320 x 2868, 1290 x 2796 and 1260 x 2736 in portrait. Files must be PNG or JPEG in sRGB with no transparency. Get those three right and the upload goes through.
Below are the specific errors, what each one actually means, and the export settings that make the problem go away permanently.
Dimension Mismatches
This is the most common failure and it's usually off by a handful of pixels.
A design tool exporting at 2x from a 660 x 1434 frame gives you 1320 x 2868, which is correct. Exporting from a 663-point frame gives you 1326 x 2872, which is rejected outright with no explanation of which dimension was wrong.
Simulator captures are the other common source. A simulator running at a scaled resolution produces a file that looks right and isn't, and the difference doesn't show until upload.
The fix is to check the actual pixel dimensions of the exported file before uploading rather than trusting the export settings. On any platform, open the file properties and read the numbers.
One genuinely useful simplification in 2026: you only need to supply screenshots for the largest display in each family. Provide the 6.9-inch iPhone set and Apple scales down for smaller devices automatically, which means one correct set instead of five. Our iPhone screenshot sizes guide has the full table.
Apple publishes the accepted dimensions per device class in its screenshot specifications reference, which is the only source worth trusting when a blog post and your export disagree.
A design tool exporting at 2x from a 660 x 1434 frame gives you 1320 x 2868, which is correct. Exporting from a 663-point frame gives you 1326 x 2872, which is rejected outright with no explanation of which dimension was wrong.
Simulator captures are the other common source. A simulator running at a scaled resolution produces a file that looks right and isn't, and the difference doesn't show until upload.
The fix is to check the actual pixel dimensions of the exported file before uploading rather than trusting the export settings. On any platform, open the file properties and read the numbers.
One genuinely useful simplification in 2026: you only need to supply screenshots for the largest display in each family. Provide the 6.9-inch iPhone set and Apple scales down for smaller devices automatically, which means one correct set instead of five. Our iPhone screenshot sizes guide has the full table.
Apple publishes the accepted dimensions per device class in its screenshot specifications reference, which is the only source worth trusting when a blog post and your export disagree.
Alpha Channel and Transparency
"Screenshots can't contain transparency" or a generic invalid-file error usually means your PNG has an alpha channel — even when nothing in the image is actually transparent.
This catches people constantly because design tools export PNGs with an alpha channel by default. The image looks completely opaque and the channel is still there in the file.
Two fixes. Export as JPEG, which has no alpha channel by definition and is fine for screenshots. Or flatten the PNG onto a solid background before export — in most tools that means adding an opaque background layer behind everything.
If you're using a mockup generator, check what it outputs. Anything producing a framed device on a transparent background will fail, which is why PlayMockup exports place the frame on a solid canvas.
The related trap is a drop shadow at the canvas edge. It looks like a design flourish and it's semi-transparent pixels along the border, which is enough to trigger the same rejection.
This catches people constantly because design tools export PNGs with an alpha channel by default. The image looks completely opaque and the channel is still there in the file.
Two fixes. Export as JPEG, which has no alpha channel by definition and is fine for screenshots. Or flatten the PNG onto a solid background before export — in most tools that means adding an opaque background layer behind everything.
If you're using a mockup generator, check what it outputs. Anything producing a framed device on a transparent background will fail, which is why PlayMockup exports place the frame on a solid canvas.
The related trap is a drop shadow at the canvas edge. It looks like a design flourish and it's semi-transparent pixels along the border, which is enough to trigger the same rejection.
Colour Profile Problems
The third failure is colour space. Apple wants sRGB, and design tools increasingly default to Display P3 because that's what modern screens support.
A P3 file often uploads without complaint and then renders with visibly different colours in the store than in your design tool. Sometimes it's rejected outright. Either outcome is avoidable.
In Figma, choose sRGB in the export settings. In Photoshop, use Export As with the sRGB conversion checked rather than Save As. In Sketch, set the document colour profile before exporting rather than after.
The symptom that tells you this happened: your brand colour looks slightly duller or more saturated on the store page than in your source file. That's a profile conversion happening somewhere you didn't control.
It's worth fixing once at the export preset level rather than per file, since every screenshot you ever produce goes through the same path.
A P3 file often uploads without complaint and then renders with visibly different colours in the store than in your design tool. Sometimes it's rejected outright. Either outcome is avoidable.
In Figma, choose sRGB in the export settings. In Photoshop, use Export As with the sRGB conversion checked rather than Save As. In Sketch, set the document colour profile before exporting rather than after.
The symptom that tells you this happened: your brand colour looks slightly duller or more saturated on the store page than in your source file. That's a profile conversion happening somewhere you didn't control.
It's worth fixing once at the export preset level rather than per file, since every screenshot you ever produce goes through the same path.
The Errors That Aren't About the File
Some rejections come after upload succeeds, during review, and those are content rules rather than technical ones.
Screenshots must show the actual app. Concept art, marketing renders and screens from a future version all breach that, and it's the most common content rejection.
Device frames inside the screenshot are allowed, but the frame must match a current Apple device and shouldn't be a competitor's hardware. An Android frame in an App Store screenshot is an easy rejection — our comparison of App Store versus Play Store screenshots covers where the two stores' rules diverge.
Pricing claims, awards and "#1 app" text need to be accurate and current. Stale claims get flagged on resubmission even if they passed a year ago.
And anything implying functionality the app doesn't have — a feature shown that requires a subscription without saying so — falls under misleading metadata, which is a slower and more painful rejection to resolve than a wrong pixel count.
Screenshots must show the actual app. Concept art, marketing renders and screens from a future version all breach that, and it's the most common content rejection.
Device frames inside the screenshot are allowed, but the frame must match a current Apple device and shouldn't be a competitor's hardware. An Android frame in an App Store screenshot is an easy rejection — our comparison of App Store versus Play Store screenshots covers where the two stores' rules diverge.
Pricing claims, awards and "#1 app" text need to be accurate and current. Stale claims get flagged on resubmission even if they passed a year ago.
And anything implying functionality the app doesn't have — a feature shown that requires a subscription without saying so — falls under misleading metadata, which is a slower and more painful rejection to resolve than a wrong pixel count.
An Export Preset That Just Works
Set this up once and stop thinking about it.
Canvas at 1320 x 2868 for the 6.9-inch iPhone class. Solid background layer at the very bottom of the stack, covering the whole canvas. Colour profile sRGB. Export as PNG at 1x from that canvas, or JPEG at maximum quality if you'd rather avoid alpha entirely.
Before uploading, check three things: the file's pixel dimensions, the file size (under Apple's limit, which is generous), and that opening it shows no checkerboard where transparency would be.
Keep the source file at the export dimensions rather than designing at an arbitrary size and scaling. Scaling introduces the off-by-a-few-pixels problem that causes most rejections.
If you produce screenshots regularly, automate the framing and export rather than repeating it manually — PlayMockup outputs at store-correct dimensions with a solid background, which removes two of the three failure modes before they happen.
Canvas at 1320 x 2868 for the 6.9-inch iPhone class. Solid background layer at the very bottom of the stack, covering the whole canvas. Colour profile sRGB. Export as PNG at 1x from that canvas, or JPEG at maximum quality if you'd rather avoid alpha entirely.
Before uploading, check three things: the file's pixel dimensions, the file size (under Apple's limit, which is generous), and that opening it shows no checkerboard where transparency would be.
Keep the source file at the export dimensions rather than designing at an arbitrary size and scaling. Scaling introduces the off-by-a-few-pixels problem that causes most rejections.
If you produce screenshots regularly, automate the framing and export rather than repeating it manually — PlayMockup outputs at store-correct dimensions with a solid background, which removes two of the three failure modes before they happen.
When the Upload Still Fails
If dimensions, alpha and colour profile all check out and it still won't upload, work through these in order.
Try a different browser. App Store Connect's uploader has a long history of failing silently in one browser and working in another, and Safari and Chrome behave differently on large files.
Try uploading a single file rather than a batch. Batch uploads fail as a group when one file is bad, and the error rarely identifies which one.
Check the file isn't a JPEG with a .png extension, or vice versa. Renaming a file doesn't change its format, and the uploader reads the actual bytes.
Re-export rather than re-saving. A file that's been through several tools can carry metadata that confuses the validator, and a clean export from the source removes it.
If all of that fails, upload through Transporter instead of the web interface. It gives properly specific error messages, which is the thing the web uploader is worst at.
Try a different browser. App Store Connect's uploader has a long history of failing silently in one browser and working in another, and Safari and Chrome behave differently on large files.
Try uploading a single file rather than a batch. Batch uploads fail as a group when one file is bad, and the error rarely identifies which one.
Check the file isn't a JPEG with a .png extension, or vice versa. Renaming a file doesn't change its format, and the uploader reads the actual bytes.
Re-export rather than re-saving. A file that's been through several tools can carry metadata that confuses the validator, and a clean export from the source removes it.
If all of that fails, upload through Transporter instead of the web interface. It gives properly specific error messages, which is the thing the web uploader is worst at.
Building a Pre-Upload Checklist
Rejections cost more than the minutes they take to fix, because they usually arrive when you're trying to ship. A four-item check before every upload removes almost all of them.
First, open one exported file and read its actual pixel dimensions from the file properties. Not the export settings — the file.
Second, confirm no transparency by checking the file opens without a checkerboard and, if you're unsure, re-export as JPEG to sidestep alpha channels entirely.
Third, confirm the colour profile is sRGB, ideally by baking it into an export preset rather than remembering each time.
Fourth, look at the content with fresh eyes for the things review catches rather than upload: placeholder copy, a stale award claim, a competitor's device frame, a feature that no longer exists in the build you're submitting.
That last one is the expensive category. A dimension error costs five minutes. A misleading-metadata rejection costs a review cycle, and if you're shipping to a deadline that's the difference between launching this week and next.
First, open one exported file and read its actual pixel dimensions from the file properties. Not the export settings — the file.
Second, confirm no transparency by checking the file opens without a checkerboard and, if you're unsure, re-export as JPEG to sidestep alpha channels entirely.
Third, confirm the colour profile is sRGB, ideally by baking it into an export preset rather than remembering each time.
Fourth, look at the content with fresh eyes for the things review catches rather than upload: placeholder copy, a stale award claim, a competitor's device frame, a feature that no longer exists in the build you're submitting.
That last one is the expensive category. A dimension error costs five minutes. A misleading-metadata rejection costs a review cycle, and if you're shipping to a deadline that's the difference between launching this week and next.
Frequently asked questions
What size should App Store screenshots be in 2026?
Lead with the 6.9-inch iPhone class at 1320 x 2868 portrait. That class also accepts 1290 x 2796 and 1260 x 2736. Apple scales your largest-display set down for smaller devices, so one correct set usually covers the whole listing.
Why does App Store Connect say my screenshot has transparency?
Your PNG has an alpha channel, even if nothing looks transparent — most design tools add one by default. Export as JPEG, or flatten the image onto an opaque background layer first. Watch for drop shadows bleeding off the canvas edge too.
Do App Store screenshots need to be sRGB?
Yes. Display P3 exports either get rejected or render with shifted colours on the store page. Set sRGB in your export settings rather than converting afterwards, and fix it at the preset level so every future export is correct.
Can I use device frames in App Store screenshots?
Yes, provided the frame matches a current Apple device. An Android frame in an App Store listing is a straightforward rejection — our [store comparison guide](/blog/app-store-vs-play-store-screenshots) covers where the two platforms' rules differ.
What should I do if the upload keeps failing with no clear error?
Upload one file at a time rather than a batch, try a different browser, and confirm the extension matches the actual format. If it still fails, use Transporter instead of the web uploader — its error messages are far more specific.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.