For current App Store submissions, start with a 6.9-inch iPhone screenshot at 1290 × 2796 pixels and a 13-inch iPad screenshot at 2048 × 2732 pixels. Apple also lets you upload up to 10 screenshots per language, so you need a process that keeps dimensions exact while making localization manageable.
If you're reading this after App Store Connect rejected a build for screenshot sizing, you're in familiar territory. This usually happens at the end of a release cycle, when the app is ready, the metadata is written, and one export from Figma or Photoshop turns out to be a few pixels off, the wrong aspect ratio, or a blurry upscale.
That frustration is avoidable. Apple's screenshot system is strict, but it isn't random. Once you understand which base sizes matter, which files App Store Connect accepts, and how Apple groups devices, the job gets simpler. The main challenge starts after that: keeping those assets correct across every localization without rebuilding your screenshot set by hand for each market.
This guide treats App Store screenshot dimensions as both a technical requirement and an operational workflow. The exact pixel sizes matter. So do your export settings, file formats, and review-safe creative choices. But if you publish internationally, your screenshot process also needs to survive translated text, layout expansion, and repeatable exports at scale.
Table of Contents
- Introduction
- App Store Screenshot Dimensions Quick Reference Table
- Detailed iPhone Screenshot Requirements
- Detailed iPad Screenshot Requirements
- App Store Connect Rules and Best Practices
- Common Pitfalls and How to Avoid Them
- How to Export Pixel-Perfect Screenshots
- Scaling Screenshots for International Markets
- Frequently Asked Questions
Introduction
Screenshot rejection usually comes from one of three problems. The file dimensions are wrong, the export has been scaled instead of rendered at native size, or the team built one English set and then improvised when localization started to pile up.
Apple's current requirements are narrower than many older guides suggest. In recent guidance, the main base submissions are the 6.9-inch iPhone and the 13-inch iPad, while the 12.9-inch iPad format is treated as legacy for older iPad Pro models, as noted in SplitMetrics' summary of Apple's screenshot requirements. Apple also supports up to 10 screenshots per localization, which matters because your screenshot system has to work not just once, but across every language you publish.
Practical rule: Treat screenshots like release assets, not marketing afterthoughts. If the dimensions are wrong, the listing workflow breaks no matter how polished the design looks.
The good news is that the job becomes predictable once you separate two concerns. First, you need the exact device-class dimensions Apple accepts. Second, you need a repeatable production workflow that can swap copy, preserve layout, and export clean files every time.
That's where teams often lose time. The design work isn't the bottleneck. The rework is.
App Store Screenshot Dimensions Quick Reference Table
Apple's current App Store Connect specs require one of the listed base resolutions per device class, and App Store Connect accepts .jpeg, .jpg, and .png files with 1 to 10 screenshots per app version, according to Apple's screenshot specifications.
Use the table below as a working reference. Typically, the point isn't to create assets for every device. It's to choose the right accepted base size for the device class you support and keep every export exact.
2026 App Store Screenshot Dimensions
| Device Group | Display Size | Portrait Dimensions (px) | Landscape Dimensions (px) |
|---|---|---|---|
| iPhone | 6.9-inch | 1290 × 2796 | 2796 × 1290 |
| iPhone | 6.7-inch | 1320 × 2868 | 2868 × 1320 |
| iPhone | 6.1-inch | 1179 × 2556 | 2556 × 1179 |
| iPhone | 6.5-inch legacy | 1284 × 2778 | 2778 × 1284 |
| iPhone | 5.8-inch | 1170 × 2532 | 2532 × 1170 |
| iPhone | 5.5-inch legacy | 1242 × 2208 | 2208 × 1242 |
| iPad | 13-inch / 12.9-inch class | 2048 × 2732 | 2732 × 2048 |
| iPad | 11-inch | 1668 × 2388 | 2388 × 1668 |
| iPad | 10.9-inch | 1640 × 2360 | 2360 × 1640 |
| iPad | 11-inch alternate class | 1488 × 2266 | 2266 × 1488 |
How to use this table
A few choices make this simpler:
- Start with accepted base sizes: Don't invent your own canvas and hope Apple scales it cleanly.
- Work from the device class you ship: Universal apps need iPhone and iPad assets. iPhone-only apps don't.
- Keep legacy sizes separate: Older iPhone and iPad formats still matter in some cases, but they shouldn't drive your whole workflow.
The fastest screenshot workflow is the one that starts with the right frame size. Most rejection problems begin before export.
Bookmark this section. It's the reference you'll return to during releases.
Detailed iPhone Screenshot Requirements
iPhone screenshot mistakes usually show up late. A designer exports clean-looking files, localization adds longer German or Japanese copy, and App Store Connect rejects the set because one size is off by a few pixels or the text no longer fits the target canvas.
The fix is operational, not just visual. Choose the exact iPhone slot first, then build and localize against that size from the start.
Which iPhone size should lead
For current submissions, the safest default is the 6.9-inch iPhone size at 1290 × 2796. Apple also accepts other current iPhone portrait sizes, including 1320 × 2868, 1179 × 2556, 1284 × 2778, and 1170 × 2532, as covered in the Apple documentation cited earlier.
The working rule is straightforward. Build each screenshot set for the exact accepted dimension you plan to upload.
That matters even more once localization starts. A headline that fits neatly on a 1290-pixel-wide canvas can break awkwardly on a narrower export, especially if your design uses large type, text blocks near the notch area, or tightly framed device mockups.
Where legacy iPhone sizes still matter
Older iPhone sizes still come up, but they should follow your support matrix, not drive it. The main legacy size many teams still check is 1242 × 2208 for 5.5-inch devices.
Use that slot only if it affects your listing strategy or your install base still justifies the extra production work. If it does, treat it as a separate deliverable with its own layout review. Do not assume a resized modern screenshot will hold up. Text wraps differently, badges shift, and CTA spacing often looks off after localization.
Screenshot operations usually get expensive as one base design becomes six languages, then six languages become multiple accepted iPhone sizes, and small spacing issues turn into a release checklist problem.
A practical production rule
Pick one primary iPhone canvas for the current release. Design on that canvas. Export at native dimensions. Then review any additional accepted sizes and language variants as separate outputs, not automatic derivatives.
Teams that skip that discipline usually run into the same issues:
- Soft text from resizing after export
- Misaligned UI chrome or status bar details
- Headline wraps that change by language
- Safe-area collisions near the top and bottom of the frame
- Last-minute manual fixes across every locale
The trade-off is simple. Building each set on the correct canvas takes more planning up front, but it saves review time, avoids rejected uploads, and makes localized screenshot batches easier to manage at scale.
A reliable iPhone workflow looks like this:
- Choose the exact iPhone upload slot
- Design on that native pixel frame
- Check copy fit before localization is finalized
- Export each file at the accepted dimensions
- QA every language and size variant before upload
That process is repetitive. It is also the fastest way to avoid App Store screenshot errors on iPhone.
Detailed iPad Screenshot Requirements
iPad screenshots are a different job. Teams often treat them like enlarged iPhone creatives, then discover the composition falls apart because the aspect ratio, spacing, and reading distance are different.
The main iPad sizes to know
Apple's accepted iPad screenshot sizes include 2048 × 2732, 1668 × 2388, 1640 × 2360, and 1488 × 2266, based on the same Apple screenshot specification reference cited earlier.
For most current workflows, the important point is that the 13-inch iPad screenshot at 2048 × 2732 is the main base requirement, while the 12.9-inch format remains relevant as a legacy path for older iPad Pro models, as noted earlier in the SplitMetrics summary.
Why iPad layouts need separate treatment
An iPad screenshot isn't just wider real estate. It changes how the UI reads.
Common iPhone patterns that often need adjustment on iPad include:
- Top-heavy title cards: Large headlines that work on iPhone can leave too much empty space on iPad.
- Tiny feature callouts: Text that feels readable on a phone mockup can look visually lost on a large portrait canvas.
- Cropped modal flows: Some interfaces rely on tighter framing on iPhone but need more intentional composition on iPad.
iPad screenshots usually fail for design reasons before they fail for technical reasons. The file uploads, but the message gets weaker.
Portrait and landscape decisions
If your app naturally lives in portrait, keep your iPad screenshots in portrait and design them specifically for that experience. If the product is strongest in a horizontal presentation, treat this presentation as a deliberate showcase format, not as an afterthought crop of the portrait version.
A solid iPad review pass should check:
| Checkpoint | What to confirm |
|---|---|
| Canvas | The file matches an accepted iPad resolution exactly |
| Layout | Headline, device frame, and UI scale feel balanced on tablet |
| Copy | Text still reads cleanly at iPad viewing size |
| Consistency | All iPad screenshots follow the same visual system |
The biggest iPad mistake is assuming the iPhone set is already done, so the iPad set should be quick. Usually it isn't.
App Store Connect Rules and Best Practices
A screenshot set can be technically correct and still create release problems. The failures usually show up later. A missing locale, the wrong screenshot order, or a text layer that was never translated forces a new export pass when the build is already in review.
The rules worth checking every release
Treat App Store Connect as a publishing system, not a file dump. The platform accepts a defined number of screenshots per localization, supports standard image formats, and applies those assets at the localization level. That matters if you ship in multiple markets, because screenshot operations scale by language, not just by device family.
Use this release checklist:
- Set the screenshot count intentionally: Upload only the frames you need for the story you want to tell. More slots do not improve conversion if the later images repeat the first ones.
- Keep file formats simple: Use .jpeg, .jpg, or .png and keep the export settings consistent across the whole set.
- Organize by locale first, device second: Teams that sort assets only by screen size usually create avoidable localization mistakes during upload.
- Lock screenshot order before handoff: If screenshot 1 is your value proposition in English, it should still be screenshot 1 in German, Japanese, and French unless there is a clear market-specific reason to change it.
- Match the app build you are submitting: Promotional copy on the screenshot must reflect the UI and features currently in review.
What improves quality without creating review risk
The safest sets are predictable to produce and easy to audit.
Start with the product experience. The first screenshot should explain the app fast, with clear UI and a message that survives translation. Decorative title cards often look polished in design review but waste your highest-visibility slot in search and browse placements.
Consistency matters more once localization starts. A layout that barely fits in English will usually break in languages with longer strings. I prefer fixed headline zones, predefined font scaling rules, and one approved template per size class. That reduces rework and keeps each market aligned with the same visual system.
For teams handling multiple languages, a documented process for publishing localized screenshots in App Store Connect prevents the common last-minute mixups: wrong locale assignment, untranslated captions, and screenshots uploaded to the wrong device group.
Review habit: Before upload, open every final PNG or JPG in Preview or Finder and verify the actual pixel dimensions, filename, locale label, and screenshot order. Do not trust the design source alone.
Good screenshot operations are repeatable. That is what keeps quality high when one set becomes twenty localized sets.
Common Pitfalls and How to Avoid Them
A screenshot set can pass design review in the morning and fail upload in the afternoon. The usual cause is not Apple being unpredictable. It is a production workflow that lets small mistakes survive until the final step, then multiplies them across every locale.
Blurry files from resizing
Blurry screenshots usually start with a shortcut. A designer works from a near-match template, exports a larger frame, then scales it down to the App Store target. The file may look acceptable in chat or slides, but App Store Connect checks the actual pixel dimensions.
The fix is operational, not cosmetic. Build each screenshot at the exact target size from the start, then export without resampling. If your team produces multiple device classes and languages, a dedicated App Store screenshot generator workflow reduces the odds of someone resizing the wrong master at the last minute.
Wrong aspect ratio with the right-looking image
This failure is easy to miss because the screenshot can look fine at a glance. The problem shows up in the details: stretched UI, uneven padding, cropped status bars, or an upload error tied to dimensions.
The common cause is a shared design file that tries to serve every size bucket. That saves time early and creates cleanup work later.
Use one approved source per accepted size bucket. Keep the frame size fixed, lock the crop area, and name exports by device class and pixel output. That gives reviewers and release managers something concrete to verify.
Localized text that no longer fits
This is the operational challenge that simple dimensions tables miss. English often fits comfortably. German expands, Japanese changes line rhythm, and French can push a headline past the safe area. One approved set quickly turns into a maintenance problem when you need the same message to stay readable across many markets.
A process that holds up under localization usually includes:
- Predefined text zones with known maximum width and height
- Copy limits by locale before design approval
- Flexible text layers instead of flattened decorative treatments
- A longest-string check before export, not after upload
- One version-controlled template per size class so every market inherits the same spacing rules
Accuracy and scale come together. If the base template is rigid, every added language creates manual fixes and inconsistency. If the template is built for translation from day one, the screenshot set stays aligned while the locale count grows.
Old UI in new screenshots
Outdated screenshots create two problems. They can trigger review questions if the listing promises flows or features that no longer match the build under review. They also waste localization work, because every obsolete source frame has to be corrected and re-exported market by market.
Tie screenshot approval to the release branch. Before upload, compare each frame against the current build, confirm the visible UI still exists, and verify that localized variants were generated from the latest source. That check takes minutes and prevents a full rework cycle later.
How to Export Pixel-Perfect Screenshots
Knowing the correct dimensions doesn't help if your export settings are sloppy. Most screenshot issues happen between the design file and the final uploaded asset.
Figma workflow
In Figma, create frames at the exact App Store target size you plan to upload. If the screenshot needs to be 1290 × 2796 or 2048 × 2732, make that the frame size, not a nearby template.
Then export at 1x. That's the part many teams miss. If you build the frame at the native size and then export at a multiplier, you're creating an avoidable opportunity for errors.
Sketch and Photoshop workflow
Sketch works well if you keep separate artboards for each device class and name them by final dimension. Photoshop is fine too, but it's easier to make accidental resampling mistakes there if multiple people touch the files.
A safe export routine in either tool looks like this:
- Name clearly: Include device class and orientation in the layer or artboard name.
- Export natively: Don't resize during export.
- Check format: Use PNG or JPEG based on your asset plan.
- Verify output: Open the exported file and confirm the pixel size.
Final validation before upload
Don't rely on memory. Use a short pre-upload check:
| Check | Pass condition |
|---|---|
| Dimensions | Exact match to the intended device class |
| Format | JPG, JPEG, or PNG |
| Readability | UI and overlaid text remain sharp |
| Naming | Files are easy to map to locale and device |
If you want a faster production route, an App Store screenshot generator workflow can reduce manual exporting, especially when you're managing multiple sizes and repeated updates.
Scaling Screenshots for International Markets
A release can be ready in English and still slip because the localized screenshots are not. The usual failure is not translation quality alone. It is a production system that cannot keep every language, device class, and pixel dimension aligned at the same time.
Teams usually get the base dimensions right once. The harder part is repeating that accuracy across French, German, Japanese, Arabic, and every other locale you support without introducing layout drift, stale text, or exports mapped to the wrong storefront. That is the gap in many screenshot dimension guides. Knowing the canvas size is only the starting point. The main operational problem is producing many localized sets that stay on spec.
Why localization creates screenshot errors
Localized screenshots fail for predictable reasons.
Text expands. Line breaks move. A headline that fits in English can wrap awkwardly in German or shrink to unreadable size in Japanese if the template was never designed for language variance. Right-to-left languages add another layer because the visual hierarchy often needs more than a text swap.
Then the file handling problems start. A designer updates one locale but not another. An older export gets uploaded because the folder naming is vague. An iPhone portrait set gets mixed with an iPad set during handoff. None of those mistakes are hard individually. They become expensive when multiplied across many locales and release cycles.
A manual workflow usually includes all of these steps:
- Extract on-screen text from each frame
- Translate copy for each target locale
- Refit the text inside the screenshot layout
- Re-export every image at the correct final dimensions
- Organize outputs by locale, device class, and orientation
- Upload without crossing files between storefronts
That workload is why localization often reintroduces the same dimension and formatting mistakes teams already solved in the source language.
What a scalable workflow looks like
The reliable approach is to treat screenshot localization as a versioned production pipeline, not a one-off design task. Keep one source template per device class. Define text-safe areas based on the longest expected copy, not the English copy. Lock export presets by final storefront size. Name files so release operations can identify locale, device, orientation, and sequence number without opening the image.
Automation helps when the app ships in several markets or updates often. If you want to reduce manual recreation, a workflow for translating App Store screenshots from a URL can shorten the path from source screenshots to localized outputs.
App Store Localizer is built for that use case. It takes a public App Store URL, extracts screenshots and metadata, translates on-screen text with cross-screenshot context, and regenerates files at exact App Store dimensions for localized publishing. That matters when the question shifts from "what size does Apple accept?" to "how do we ship 12 language sets without rebuilding every frame by hand?"
A short demo shows the difference in practice:
Screenshot localization is a layout, naming, and export discipline. Translation is only one part of it.
The teams that avoid rejection and rework do two things well. They keep dimensions exact, and they build a localization process that can repeat that accuracy at scale.
Frequently Asked Questions
Can I upload fewer than 10 screenshots
Yes. Apple allows 1 to 10 screenshots per app version in App Store Connect, based on the Apple specification referenced earlier. Fewer strong screenshots are better than filling slots with weak ones.
Which file formats does App Store Connect accept
Apple accepts .jpeg, .jpg, and .png screenshot files, according to the App Store Connect specification already cited. Keep your export process consistent so your team isn't mixing formats without a reason.
Do I need separate iPhone and iPad screenshots
If your app supports both device classes, you should prepare both sets. The iPhone and iPad layouts usually need different composition even when the core UI is the same.
Can I use one screenshot design across all languages
You can reuse the structure, but the localized text still needs to fit the layout and remain readable. In practice, that means treating localization as a screenshot production workflow, not just a translation pass.
If your screenshot process still feels fragile, fix the production system before the next release. App Store Localizer helps teams turn a single App Store URL into localized, publish-ready screenshots and metadata for supported locales, with exact App Store dimensions preserved across iPhone and iPad outputs.