App Store Screenshot Guidelines for iPhone and iPad
A submission-ready screenshot set needs more than the right pixels. It must use accepted files, match the app’s real experience, fit the correct device category, stay readable in the store rail, and remain accurate for every localization. This checklist separates Apple’s requirements from practical design recommendations.
Current App Store screenshot requirements
Apple currently accepts between one and ten screenshots for each supported device context and localization. Files may be JPEG, JPG, or PNG, but screenshots cannot contain an alpha channel or transparency. Portrait and landscape sizes are accepted when they match an exact pixel pair listed by App Store Connect.
For an iPhone app, prepare an accepted 6.9-inch screenshot set whenever possible. Apple states that the 6.5-inch category becomes required when 6.9-inch screenshots are not supplied. If the app runs on iPad, a 13-inch iPad set is required and should show the genuine large-screen interface.
- Upload 1–10 screenshots per supported context
- Use JPEG, JPG, or opaque PNG
- Match an exact accepted portrait or landscape pixel pair
- Provide 13-inch iPad assets when the app supports iPad
Show the real core experience
Apple’s accurate-metadata rule applies to screenshots and previews as well as written metadata. A screenshot should depict functionality and content that customers will receive in the submitted version. Do not invent controls, hide important limitations, show unreleased features as if they are available, or reuse an unrelated platform interface.
Clean presentation is allowed, including backgrounds, captions, and device framing. The product UI should remain the evidence behind each claim. If a headline promises one-tap automation, the screen beneath it should visibly demonstrate that workflow rather than display a generic welcome page.
- Remove test data, debug labels, and private information
- Avoid unverifiable rankings, awards, or performance claims
- Do not include price language where it does not belong
- Update screenshots when a release materially changes the interface
Build a screenshot sequence that reads quickly
The first screenshots carry most of the storytelling load. Begin with the product category and strongest user outcome, then show the main workflow and differentiating feature. Use later panels for supporting capabilities such as privacy, personalization, collaboration, offline behavior, or large-screen support.
Treat the rail as one system. Keep headline placement, type scale, device finish, and background rhythm consistent, while giving each panel a distinct message. A user should understand every headline at thumbnail size and should not need to infer what a vague adjective means.
| Position | Question to answer | Example direction |
|---|---|---|
| 1 | What valuable result does this app provide? | Plan the week in one calm view |
| 2 | How is the core task completed? | Capture every task in seconds |
| 3 | What makes the product different? | Priorities that adjust with your day |
| 4 | Why should the user trust it? | Private by default, synced when you choose |
| 5 | What completes the experience? | Your work, available on every device |
Use device frames without misrepresenting hardware
A recognizable iPhone or iPad frame can establish platform context and create consistent negative space for copy. A frameless layout can display more interface detail. Neither approach is automatically better; choose the treatment that keeps the product legible and honest.
Do not place an iPhone capture in an Android-looking device, and do not stretch phone UI into an iPad frame. Check that the frame does not cover important status, navigation, or interaction areas. When the source aspect ratio differs substantially from the target, return to the simulator and capture the correct device instead of accepting an aggressive crop.
Localize the complete visual, not only the headline
Translate the marketing copy and capture the interface in the same language. English text often expands or contracts significantly when localized, so review line breaks, type size, and safe margins for each market instead of placing translated strings into a fixed layout unchanged.
Apple can use a fallback localization when localized assets are missing. A deliberate localized set gives you more control over what customers see and keeps the visual promise aligned with the translated product page.
- Match screenshot UI language to the listing language
- Recheck punctuation and line wrapping
- Avoid embedding dates, prices, or seasonal claims that age quickly
- Keep a clean source capture for every language
Diagnose common screenshot problems before review
Most screenshot problems are easier to catch as a mismatch than as an isolated design flaw. Compare the asset with four references: the submitted build, the selected device category, the target localization, and the claim in the headline. If any pair disagrees, the image is not ready even when the file dimensions are technically valid.
A screen can also be accurate but unhelpful. Empty states, login screens, settings lists, and generic dashboards often reveal little about the reason to install. Replace them with a realistic product state that proves the panel’s promise. Keep enough interface context that a visitor can understand what changed or what action produced the result.
Finally, separate a store upload error from a creative problem. Rejected dimensions, transparency, and wrong orientation require a new export. Unreadable copy, weak order, or misleading evidence require revisiting the source and story; repeatedly resizing the same design will not solve them.
| Symptom | Likely cause | Corrective action |
|---|---|---|
| App Store Connect rejects the file | Unsupported pixel pair or alpha channel | Export an exact listed size with an opaque background |
| iPad panel looks stretched | Phone capture placed in a tablet frame | Capture the genuine iPad layout at the intended orientation |
| Headline is readable only when enlarged | Too much copy or weak contrast | Shorten the promise and protect a higher-contrast text area |
| Claim feels disconnected from the screen | Decorative or generic UI state | Capture the workflow or result that directly proves the benefit |
| Localized set feels inconsistent | Translated caption over default-language UI | Capture both interface and marketing copy in the target language |
Preserve an evidence trail for the next release
Store screenshots are release assets, not one-time marketing exports. Keep the clean capture, approved caption, device family, app build, locale, and final submitted PNG together. This record makes it possible to replace one outdated screen without guessing how the rest of the rail was produced.
Assign a stable purpose to each panel—outcome, workflow, differentiator, trust, or supporting fit—rather than identifying it only as “screen three.” When the product changes, review whether the old purpose is still strategically useful before reproducing the same order with new UI.
- Record the exact app build and capture device
- Keep fictional demo data reproducible
- Store clean sources separately from marketing exports
- Track copy approval and localization review
- Archive the exact files uploaded to App Store Connect
Final App Store submission checklist
Before upload, inspect every exported file at full size and compare the set with the build being submitted. Then confirm device family, orientation, localization, ordering, and pixel dimensions inside App Store Connect.
- Every file is opaque JPEG/JPG/PNG
- Pixel dimensions match one accepted Apple size
- iPhone and iPad sets show the correct interface
- Claims are specific, current, and visible in the product
- No personal data, debug content, or placeholder copy remains
- The first two screenshots explain the main value without extra context
Frequently asked questions
How many App Store screenshots can I upload?
Apple currently accepts one to ten screenshots for each supported device context and localization.
Can an App Store screenshot be a transparent PNG?
No. Apple says screenshots cannot contain alpha channels or transparency.
Do I need every historical iPhone size?
Usually not. Apple can scale a highest-resolution required set to smaller device sizes when the interface is consistent. Review the current Media Manager behavior for the app.
Are device frames allowed?
A frame can be used as presentation, but the screenshot must still accurately represent the app and the correct platform. Avoid misleading hardware or cropped UI.
Can I reuse iPhone screenshots for iPad?
Do not stretch phone UI into an iPad layout. If the app supports iPad, show its real large-screen experience in the required iPad category.
Should every localization have different screenshots?
When screenshots contain text or localized interface, make a matching set for that language so customers see a coherent product page.
Turn the checklist into finished store assets.
Upload real captures, add focused copy, choose the correct device size, and export an organized ZIP in the browser.
Create App Store screenshots