App Store screenshots must meet Apple’s current pixel, format, and device-display rules, and they must represent the app customers receive. Apple currently allows one to ten screenshots per supported display entry in JPEG, JPG, or PNG format, without alpha channels or transparency.
Use Apple’s live specification table when exporting. Device families and accepted dimensions change, so an old design template is not a reliable technical source. Screenshots are one part of the complete first iOS App Store submission.
The short version
- Export only dimensions listed in Apple’s current screenshot specifications.
- Use JPEG, JPG, or PNG files without transparency.
- Show the real submitted interface and reachable features.
- Verify every localization, device family, and claim before adding the version for review.
Separate technical validity from truthful content
A screenshot can pass the uploader and still create a review problem. Treat each asset as two checks:
- Technical: accepted dimensions, file type, orientation, and device family.
- Editorial: accurate interface, reachable feature, readable claim, and correct localization.
Apple’s screenshot specifications are the technical source. The App Review Guidelines are the source for accurate metadata and representations.
Do not use a conversion-focused creative review to override the technical table. Do not use a technically accepted file to justify a claim that the build cannot support.
Use the current screenshot specification table
Apple’s reference lists accepted portrait and landscape dimensions by display class and identifies when a class is required. At the time this article was verified, the table includes current iPhone 6.9-inch options such as 1260 × 2736, 1290 × 2796, and 1320 × 2868 pixels in portrait, with reversed dimensions for landscape.
Those numbers are examples from the live table, not a universal export preset. Check the complete reference for your app’s supported devices, including iPad, Apple Vision Pro, Apple Watch, Apple TV, or other platform requirements.
A reliable export workflow is:
- List every platform and device family supported by the submitted build.
- Open Apple’s current specifications.
- Mark the required display entries for that support set.
- Choose one accepted size per entry.
- Export and validate exact pixel dimensions.
- Upload to the matching App Store Connect slot.
Do not identify a screenshot only as “large iPhone.” Put the display class, orientation, pixel dimensions, locale, and sequence in the filename used by your team.
For example: iphone-6-9_1320x2868_en_01-home.png. The internal filename is not customer-facing, but it prevents an asset from landing in the wrong slot.
Capture the app, not an imagined future version
Screenshots should reflect the interface and features in the selected build. Apple’s Guideline 2.3 requires accurate metadata and representations.
Avoid:
- a Figma mockup that differs from the running app;
- controls, tabs, or data the reviewer cannot reproduce;
- a premium feature unavailable in the submitted purchase configuration;
- a desktop or web interface presented as the iOS app;
- status-bar or device treatment that implies unsupported hardware;
- a claim about an upcoming feature.
Frames, backgrounds, and concise captions can help customers understand the screen, but the central product evidence should remain truthful. If a caption says “Export any project,” the selected build and review account should support that action under the stated conditions.
Keep a screenshot-to-build manifest: each asset should point to the version and build used for capture. If the interface changes after capture, recheck the set.
Cover the required device families efficiently
App Store Connect can scale screenshots between certain display sizes according to Apple’s current upload workflow, but requirements depend on the supported platform and device family. Follow the live interface and help text rather than generating every historical device size by habit.
Apple’s upload screenshots help explains where to add localized assets and how screenshots are managed in App Store Connect.
The practical rule is to start from required high-quality source captures, then export accepted dimensions without stretching. If two device classes have different aspect ratios or UI layouts, recapture or redesign the composition rather than distorting it.
Test safe areas for captions and device frames. Important text should not be clipped in the product-page presentation. Review the set at actual phone size, not only on a desktop artboard.
Decide the sequence before designing captions
The first screenshots should explain the product’s core job, but this article focuses on compliance rather than conversion strategy. Build a factual sequence:
- core outcome or primary screen;
- main workflow;
- meaningful secondary capability;
- trust, collaboration, or settings evidence when relevant;
- purchase state only if accurately configured and reachable.
Each screenshot should add a distinct piece of evidence. Repeating the same dashboard with different slogans does not improve review clarity.
Limit captions to claims you can verify in the selected release. Avoid absolutes such as “100% secure,” “guaranteed results,” or “the best” unless you hold appropriate, current substantiation and the claim is permitted. Regulated health, finance, kids, and gambling claims need additional care and may require professional advice.
Localize the full asset, not only the caption
Each localization should make sense as a complete screen. Check:
- caption language and spelling;
- in-app interface language;
- dates, currency, units, and number formats;
- sample names and content;
- subscription prices shown by the app;
- legal or regulated wording;
- sequence order for that market.
Do not place English captions around an interface that appears in another language unless that is an intentional and accurate product experience.
A localization can also expose layout bugs. Long labels, right-to-left interfaces, and different price strings may change the evidence shown. Capture from a correctly configured app state.
Run a screenshot review against the selected build
Before upload, use a two-person check. One person opens the assets; the other reproduces each screen in the selected build.
For every screenshot, record:
| Check | Pass condition |
|---|---|
| File | Accepted type, exact dimensions, no transparency |
| Slot | Correct platform, display class, orientation, locale |
| UI | Screen matches the selected build |
| Access | Reviewer can reach the feature with supplied instructions |
| Claim | Caption is accurate and bounded |
| Data | Synthetic content contains no customer or secret information |
| Purchase | Product and entitlement state match the submission |
If a screenshot is wrong, decide whether the asset or app is wrong. Re-exporting fixes a dimension; it cannot fix a missing feature. A code or bundled-interface change requires a new build and retest.
The broader App Store submission checklist connects this asset review to metadata, access, privacy, and the final draft.
Avoid privacy and account leaks
Screenshots are public product-page assets. Never capture real customer names, email addresses, message content, access tokens, API keys, private health data, or financial details.
Seed synthetic data before capture. Review notifications, status bars, maps, calendars, and account menus, where private details are easy to miss. Flattened image files can still visibly expose secrets even when metadata has been removed.
For apps involving children or sensitive data, use an internal approval process appropriate to your obligations. This guide is not legal advice.
FAQ about App Store screenshot requirements
How many App Store screenshots can I upload?
Apple’s current screenshot specification says you can upload one to ten screenshots for an applicable display entry.
Which file formats does Apple accept?
Apple currently lists JPEG, JPG, and PNG. Images cannot include alpha channels or transparency.
Do I need screenshots for every iPhone size?
Not necessarily. Requirements and scaling behavior depend on Apple’s current display classes and your supported devices. Use the live specification and App Store Connect slots for this release.
Can screenshots include text and device frames?
They can include designed elements, but the result must accurately represent the app and comply with Apple’s metadata rules. Keep the real interface legible and claims supportable.
Do screenshot changes require a new build?
Changing editable screenshot metadata does not by itself change the binary. If the screenshot reveals that the submitted app is missing or misrepresents a feature, the underlying app may require a corrected build.
Conclusion
Start with Apple’s current table, not an inherited template. Export accepted files for the required device families, then verify every screen and caption against the selected build.
Your next action is to label each existing screenshot with its pixel dimensions, locale, display class, and source build. Any asset missing one of those facts needs review before upload.