LaunchLint Academy
The short answer
- App Store screenshots are both a technical upload asset and the most prominent visual sales surface. A strong set therefore has to meet current size rules, represent the shipped product truthfully, and communicate a useful outcome within its opening sequence.
- This guide separates required formats, device coverage, creative direction, localization, and release QA. It gives Expo and React Native teams a repeatable workflow instead of a last-minute collection of unrelated exports.
What Apple actually requires
Apple currently allows one to ten screenshots for each supported device size. Files must be JPEG, JPG, or PNG, and transparency is not accepted. App previews are optional, while screenshots for required device classes form part of the product page submission.
The specification separates iPhone and iPad display classes. If the build runs on iPad, include suitable iPad assets. Do not assume one phone export automatically covers every required slot or communicates the product well on a much larger screen.
Technical baseline
- Provide one to ten screenshots for each required device size
- Export JPEG, JPG, or PNG without an alpha channel
- Use only pixel dimensions listed by App Store Connect
- Create iPad assets when the app supports iPad
- Inspect processing errors immediately after upload
Plan exact dimensions and device classes
For current large iPhones, Apple accepts several exact portrait and landscape dimensions, including 1260 × 2736, 1290 × 2796, and 1320 × 2868 pixels. Current 13-inch iPad portrait options include 2064 × 2752 and 2048 × 2732 pixels. Always treat the official table as the current authority.
Build templates around a verified output dimension rather than a marketing device name. That keeps naming, export validation, and QA stable when new hardware arrives or App Store Connect changes which display class receives the primary upload.
Dimension matrix
- List target platforms and devices supported by the build
- Record accepted dimensions and the verification date
- Create one master canvas per aspect ratio
- Validate width and height automatically after export
- Reopen the official specification before every release
Show the shipped app, not a fictional mockup
A screenshot should represent real use of the app. Backgrounds, concise headlines, and device frames can support the message, but they should not advertise a feature that is missing from the submitted build or behaves differently during review.
AI-built products accumulate prototype screens quickly. Old components, demo paywalls, and abandoned flows can survive in design files after the implementation changes. Tie every marketing frame to a reproducible route and state in the actual release candidate.
Evidence for every frame
- Map each image to a real route or product capability
- Never present a planned feature as already available
- Keep sample data plausible and clearly illustrative
- Do not fabricate misleading permission or system dialogs
- Record the source build number and capture date
Turn the gallery into a short product story
The opening three frames usually carry most of the message. Lead with the primary outcome, follow with the central workflow, and then show credible proof or a result. A problem-led sequence is normally clearer than a chronological tour of every navigation tab.
Give every card one job. Short, concrete headlines scan faster than feature inventories. If visitors must read tiny interface labels before they understand why two frames differ, the visual hierarchy still needs work.
A useful sequence
- Frame 1: strongest outcome or core benefit
- Frame 2: central workflow
- Frame 3: evidence or completed result
- Later frames: differentiation, integrations, and trust
- Final frame: a meaningful close rather than repetition
Localize without breaking the layout
App Store Connect supports localized screenshots. The result is only convincing when the overlay and visible interface use the same language. Dates, currency, numbers, names, and sample content also need to make sense for the target market.
Design text areas for longer German, French, Spanish, or Italian wording from the beginning. Do not shrink translations until they become unreadable. Flexible zones, line limits, and editorial rewriting are safer than literal copy fitted at any cost.
Localization QA
- Use the same language in overlay and visible app UI
- Apply regional date, currency, and number formats
- Check for truncation and covered interface controls
- Remove stale exports from other locales
- Preview every locale separately in App Store Connect
Use a repeatable capture workflow
Define test accounts, fixture data, device settings, and exact app states before capture. Consistent time, status bar, appearance, and content make the gallery feel intentional. Personal messages, real account details, and sensitive notifications should never enter the source assets.
Automation can capture screens and validate dimensions, but it cannot select the clearest product story by itself. Store raw capture, editable master, and final export separately so copy can change without reconstructing every app state.
Production workflow
- Create a shot list with route, state, and message
- Use dedicated accounts and deterministic fixture data
- Capture clean sources without personal information
- Keep the editable master centrally and version it
- Label exports with locale, device class, and version
Run visual and technical acceptance
Review the entire order as a small store preview, not only as full-size artwork. Contrast, type size, pacing, and variation have to survive thumbnail presentation. Repeated screens or inconsistent frames make even a capable product look unfinished.
Technical checks should validate dimensions, format, alpha channel, orientation, and file integrity automatically. A human then compares every frame with the release build. Both layers are necessary because a valid image can still make a false product claim.
Final acceptance
- Every file has an accepted exact dimension
- No alpha channel, empty border, or wrong orientation
- Headlines remain readable at preview size
- The sequence works without hidden context
- Every shown capability exists in the release build
Upload early and keep the set current
Upload before the final submission window so processing and size problems do not become release blockers. Inspect every localization and device class in the completed product page state; a successful file transfer is not the same as content approval.
After meaningful interface changes, screenshot review belongs in the definition of done. A matrix containing frame, route, locale, dimension, build number, and last review date exposes stale assets before customers or reviewers find the mismatch.
Release gate
- All target locales and device classes are complete
- App Store Connect previews have been reviewed
- No warning or processing state remains unnoticed
- The asset matrix points to the current build
- An owner is assigned for post-release maintenance
Frequently asked questions
How many screenshots can I upload?
Apple currently permits between one and ten screenshots for each supported device size.
Do I need every iPhone hardware size?
Not every model. Cover the display classes required by App Store Connect with an accepted exact dimension and verify the current specification.
Are iPad screenshots required?
If the submitted app runs on iPad, provide suitable screenshots for the required iPad display class.
Can screenshots include text and device frames?
Yes, provided the result remains truthful, clearly represents the real app, and does not imply unavailable functionality.
Can all locales use the same image set?
Sometimes technically, but a credible localized page aligns the overlay, visible interface, and regional formats for each audience.