App Store Screenshot Dimensions: 2026 Pixel & Ratio Guide
Get the 2026 guide to app store screenshot dimensions. Exact pixel sizes, aspect ratios, and file requirements for Apple & Google Play. Avoid rejection!
You're usually here at the worst possible moment. The build is done. QA has signed off. The metadata is loaded into App Store Connect or Google Play Console. Then the upload fails on something that feels trivial: screenshot dimensions.
That error isn't trivial. It can stall a release, trigger another review cycle, and force your team back into asset production when everyone thought the launch work was finished. In mobile deployment, screenshot mistakes are one of those avoidable problems that still catch experienced teams because the stores don't judge them by intent. They judge them by exact compliance.
Most articles on app store screenshot dimensions stop at a short list of “main sizes.” That's not enough in practice. A primary rejection trap is older and non-flagship device support, especially on iOS, where teams assume Apple's scaling will save them and then learn the hard way that certain slots still demand exact pixel matching. That nuance causes up to 40% of upload errors for non-Max iPhone models according to the provided 2025 App Store Connect error-log summary tied to Apple's screenshot specifications (Apple screenshot specifications reference).
This guide treats screenshot prep the way release specialists do. Exact dimensions. Format rules. What gets rejected. What works cleanly for React Native and Expo pipelines. And where teams waste time by exporting the wrong master assets.
Table of Contents
- Introduction Why Screenshot Dimensions Are Critical
- Quick Reference Cheatsheet Apple vs Google Play
- Apple App Store Screenshot Requirements
- Google Play Store Screenshot Requirements
- Complete iOS Device Screenshot Dimension Table for 2026
- Export Best Practices for File Format and Quality
- Common Rejection Pitfalls and How to Avoid Them
- Automating Screenshots for Faster Submissions
- Frequently Asked Questions
Introduction Why Screenshot Dimensions Are Critical
Screenshot compliance sits at the intersection of design, release engineering, and store review. That's why it causes so much trouble. Design teams think in layouts and messaging. Developers think in device classes and export pipelines. App stores care about exact output files.
On Apple's side, that means pixel-for-pixel matching. If your screenshot is even slightly off, the uploader or reviewer can treat it as a quality problem rather than a creative one. That distinction matters because a blurry or distorted image doesn't just look weak. It can stop the submission.
On Google Play, the rules are looser, but that flexibility creates a different failure mode. Teams assume “close enough” is acceptable, export one phone set, and forget that Android listings often need deliberate coverage across multiple device types because Google doesn't auto-scale your screenshots across categories the way Apple does.
Why this fails at the last minute
Many teams make one of three mistakes:
- They export from the wrong master size. A designer works from a convenient artboard instead of the actual store dimension.
- They trust automatic scaling too much. That's where older iPhone slots become a problem.
- They optimize visuals before they validate compliance. Good-looking screenshots still fail if the file specs are wrong.
Practical rule: Validate screenshot dimensions before copy overlays, localization, and final compression. If the base asset is wrong, every derivative file is wrong.
This is one of those launch tasks where precision beats speed at first, because precision is what gives you speed later.
Quick Reference Cheatsheet Apple vs Google Play
A common submission failure looks like this: the creative is approved, the copy is localized, and the upload still stalls because one iPhone screenshot is off by a small margin on an older supported display. Apple treats that as a file compliance problem. Google Play usually does not. That difference changes how experienced release teams build screenshot sets.
| Requirement | Apple App Store | Google Play |
|---|---|---|
| Screenshot count | Up to 10 screenshots per localization. At least 1 is required to submit. | 2 to 8 screenshots per device type. |
| Dimension model | Exact, device-class-based, pixel-perfect. | Range-based, within store limits. |
| Base submission approach | Primary iPhone and iPad base sizes cover standard submissions, but older supported display slots still create exact-dimension traps during production and upload. | One valid size can pass if it stays within platform limits, but separate assets often perform better across phones, tablets, and other Android form factors. |
| File formats | Flattened JPEG or PNG, RGB, no transparency. | JPEG or PNG, RGB, no alpha. |
| Scaling behavior | Apple can scale accepted assets in some cases, but only from valid source dimensions tied to supported display classes. | Google Play is more tolerant on sizing, but it does not solve merchandising coverage for every device category. |
| Review risk | Pixel mismatch, soft exports, and wrong legacy-display dimensions are frequent causes of upload errors. | Weak category coverage, cropped UI, and promotional images that misrepresent in-app experience cause more trouble than raw dimension compliance. |
The operational difference
Apple requires production discipline. The practical trap is not the current flagship size. It is the older, non-flagship device slot that someone assumes Apple will forgive. In our deployment work at LetsDeployIt, that is the mistake that surfaces late, after teams have already exported overlays, translated captions, and queued release candidates.
Google Play gives teams more room on raw dimensions, but that flexibility creates a different trade-off. A single phone set may meet the technical rules and still leave the listing weak on tablets or other Android categories. Compliance is easier. Coverage planning is harder.
For teams shipping to both stores, the lowest-risk order is simple:
- Build exact iOS source files first.
- Validate every required Apple display output, including older supported sizes.
- Adapt approved masters into Android variants by device category.
- Run a final file check before upload, not after rejection.
That sequence saves rework. If the Apple source set is wrong, every resized derivative is wrong too.
Apple App Store Screenshot Requirements
A release can be fully tested, approved by marketing, and ready to ship. Then App Store Connect blocks the build because one screenshot for an older iPhone slot is off by a few pixels.
That is the Apple screenshot problem in practice. The current rules are easier to manage than the old device-by-device sprawl, but the expensive mistakes still happen in the long tail of supported displays. At LetsDeployIt, that is the pattern we see repeatedly: teams prepare polished 6.9-inch and iPad assets, then lose time on an older phone class they assumed Apple would resize for them.
The base submission shift
Apple now centers iPhone and iPad screenshot production around a smaller set of primary submission classes. For many organizations, that reduces design overhead and makes it easier to maintain one approved visual system across releases.
The operational benefit is real. Fewer base canvases mean fewer localized exports, fewer caption variants, and fewer chances to introduce layout drift between phone and tablet sets.
The risk comes later. Teams often treat the simplified base requirement as permission to reuse one flagship export everywhere.
The exact supported display trap
Apple accepts screenshots by slot, and each slot expects the exact pixel dimensions for that display class. Close aspect ratios are not reliable. Resized variants that look correct to a human reviewer can still fail in upload.
This is the nuance other guides usually skip. The rejection pattern is rarely the obvious flagship size. It is the older, non-flagship device requirement that still has to be matched exactly when you choose to populate that supported display.
In live submission work, this accounts for a large share of screenshot upload failures. The mistake is usually simple: a team exports a clean master for the newest iPhone, duplicates the set, and drops that same file into a smaller device slot. App Store Connect treats it as the wrong asset, not a near match.
A polished screenshot set still fails if even one populated Apple slot uses the wrong native pixel size.
What actually works
Handle Apple screenshots as production assets with strict slot mapping.
- Build from Apple-approved base canvases. Start with the current accepted iPhone and iPad master sizes for the release cycle you are targeting.
- Map every populated display slot before export. If the listing includes older supported iPhones or alternate iPad classes, confirm the exact pixel dimensions first and export specifically for that slot.
- Keep orientation consistent within each set. Portrait and horizontal orientations are both accepted, but each image in a given device class needs the correct aspect ratio and a consistent presentation.
- Export flattened files only. Use RGB PNG or JPEG files with no transparency and no layered artifacts from your design tool.
- Review legibility at native size. Text that survives on a large master can become weak after resizing into smaller supported outputs.
One more trade-off matters here. A single high-resolution master speeds up design review, but it can hide production mistakes until upload day. Separate, named exports for each Apple slot take longer upfront and save time during submission.
What doesn't work
These workflows create avoidable failures:
| Bad workflow | Why it fails |
|---|---|
| Exporting directly from a generic Figma or Sketch frame | The frame often misses Apple's exact pixel grid for the target slot |
| Reusing one 6.9-inch iPhone file across smaller iPhone slots | The upload can fail on resolution mismatch even if the composition looks fine |
| Upscaling a smaller screenshot to fill a larger class | Soft text, blurred UI, and compression artifacts become obvious fast |
| Mixing captures from different devices without normalizing margins and safe areas | The gallery looks inconsistent and can expose process gaps during review |
| Batch-generating screenshots without slot validation | Automation can produce dozens of wrong files in minutes |
Teams using React Native, Expo, or scripted simulator capture should be extra strict here. Automation shortens production time, but it also multiplies mistakes if the export map is wrong. The safest workflow is to validate device classes first, then run the batch.
Google Play Store Screenshot Requirements
A common release-week mistake looks like this. The Android build is ready, the listing is half-complete, and the team assumes Google Play will accept any reasonably large screenshots because Apple is the store with the strict pixel rules. Then the Play Console flags aspect ratio, file size, or device grouping issues, and the submission stalls on assets that should have been finished earlier.
Google Play gives you more flexibility than Apple, but it still enforces hard limits. Screenshots must be between 320 px and 3840 px, the longest side cannot be more than twice the shortest side, files must be JPEG or 24-bit PNG with no alpha, and each file must stay under 8 MB. You also need 2 to 8 screenshots per device type.
That flexibility changes the job. On Apple, the failure pattern is exact resolution mismatch, especially on older device classes. On Google Play, the failure pattern is looser but still expensive. Teams upload assets that pass basic size checks yet look soft, crop badly in listing previews, or misrepresent the interface shown on tablets and larger Android layouts.
What Google Play actually expects
The safest approach is to prepare screenshots by presentation group, not as one universal Android set.
If the app experience is materially different on phones, tablets, or foldables, the screenshots should reflect that difference. Reusing a phone capture for a tablet listing usually saves an hour and costs far more during review, especially when spacing, navigation, or multi-pane layouts change.
Use this standard before upload:
- Phone screenshots: Export at a resolution that keeps UI text sharp on dense screens. Avoid oversized files that force unnecessary compression.
- Tablet screenshots: Capture the actual tablet interface. Do not stretch or pad phone screenshots to fill the frame.
- Foldable screenshots: Upload them only if the foldable experience is meaningfully distinct and polished enough to market on its own.
- UI accuracy: Show the live product. Promotional overlays, outdated pricing, placeholder states, and unreleased features create avoidable policy risk.
At LetsDeployIt, this is one of the recurring Android cleanup jobs we see before launch approval. The screenshots are technically valid, but the asset set was built from one design master without checking how the Play listing presents different device experiences.
Production choices that prevent rework
For Google Play, pick a screenshot size strategy that matches the product, not just the design file. A high-resolution master still helps with review and copy changes, but final exports should be generated for the device groups you plan to show in the store.
A practical workflow looks like this:
- Capture from the actual Android layout for each device group in scope.
- Export within Play Console limits, with no transparency.
- Check text and key UI elements at actual preview size, not just zoomed-in in Figma.
- Confirm the screenshot order tells a coherent product story on phones first, then on larger devices if included.
One detail gets missed often. Google Play may be more tolerant on dimensions, but tolerance does not fix weak assets. Soft type, mismatched framing, and recycled phone images on tablet listings are easy for reviewers and users to spot.
That is the trade-off. Apple punishes the wrong pixels. Google Play punishes weak judgment.
Complete iOS Device Screenshot Dimension Table for 2026
Release week failures often come from a simple mistake. The screenshots look right in Figma, the copy is approved, and App Store Connect still rejects the upload because one older device slot is off by a few pixels.
That is the trap this table is built to prevent. Apple's current iPhone and iPad screenshot groups are only part of the job. The costly misses usually happen on legacy and non-flagship device classes that teams assume will auto-scale cleanly.
Core reference table
Use these dimensions as exact export targets for the device classes you choose to populate.
| Device | Screen Size | Portrait Dimensions (px) | Landscape Dimensions (px) |
|---|---|---|---|
| iPhone base submission | 6.9-inch | 1320 x 2868 | 2868 x 1320 |
| iPhone 15 Pro / similar supported 6.1-inch class in verified data | 6.1-inch | 1179 x 2556 | 2556 x 1179 |
| iPhone Plus / Pro legacy class in verified data example | 6.5-inch | 1242 x 2688 | 2688 x 1242 |
| iPad base submission | 13-inch | 2064 x 2752 | 2752 x 2064 |
| iPad legacy base noted in prior cycle milestone | 13-inch / legacy 12.9-inch submission context | 2048 x 2732 | 2732 x 2048 |
| iPhone Plus legacy class | 5.5-inch | 1242 x 2208 | 2208 x 1242 |
How to use this table without creating upload errors
Treat each row as a separate delivery spec. Near-match exports are a common reason screenshots fail validation, especially on the older iPhone and iPad classes that teams did not actively design around.
At LetsDeployIt, we see the same pattern in pre-submission reviews. A team builds a polished 6.9-inch master, scales it down for 6.5-inch or 5.5-inch slots, and assumes Apple will accept the file because the layout still looks sharp. The problem is not visual quality. The problem is that App Store Connect checks exact pixel dimensions for the slot you are filling.
Use a simple handoff rule:
- Define the device class you are submitting for.
- Export to that class's exact portrait or horizontal resolution.
- Name files by device class, orientation, and locale.
- Validate every asset before upload, especially legacy sizes.
The practical trade-off is time versus risk. Exporting one universal master is faster at the design stage. Exporting exact files for each required device class is what prevents rejection loops, last-minute resizing, and rushed re-exports after metadata is already queued for review.
One more point matters here. You do not always need to upload every row in the table, but every row you do upload must be pixel-perfect for that slot. That distinction saves time and prevents the older-device errors that get missed until the final submission pass.
Export Best Practices for File Format and Quality
Dimensions get the file accepted by the uploader. Export quality decides whether the screenshots still look sharp after the store processes them.
Teams usually lose time here in one of two ways. They over-compress and soften the UI, or they keep a visually clean file that fails because the export settings carried hidden problems such as transparency, the wrong color profile, or a resized canvas. At LetsDeployIt, we treat export as a release task, not a design afterthought, because the mistakes show up late and create preventable rework.
PNG versus JPEG in real app listings
For product UI, PNG is usually the better default. It holds text, icons, dividers, and small interface details without the artifacting that JPEG introduces at lower file sizes.
JPEG can still work for image-heavy screens, lifestyle composites, and backgrounds with large gradients. The trade-off is simple. Smaller files come at the cost of edge clarity. That cost is easy to miss in a design tool and obvious in store preview.
Platform rules are straightforward. Apple accepts flattened PNG or JPEG files in RGB without transparency, and Google Play also accepts PNG or JPEG files without alpha. File size limits matter, but visual clarity matters just as much. A screenshot can meet the upload rule and still look weak enough to trigger review comments or reduce conversion.
Export for the slot you are actually filling
This is the part many guides skip. File format decisions only help if the export is built for the exact slot, including older device classes that are easy to ignore during production.
A polished master file from a current flagship device often looks fine after resizing. App Store Connect does not judge "close enough." It checks the exact pixel output for the device class you selected. That is why older, non-flagship sizes create so many upload errors. The screenshot looks correct to the team, but the file does not match the slot specification.
For that reason, export screenshots at final size whenever possible. Do not export a large PNG, compress it later, then crop or scale it in a second step unless that step is controlled and verified. Every extra handoff increases the chance of a one-pixel mismatch, softened text, or an accidental alpha channel.
Quality checks that catch the expensive mistakes
Use a short review pass before upload:
- Check final pixel dimensions on the exported file, not the artboard
- Open the asset at 100% zoom and inspect text, tab labels, and fine lines
- Confirm the file is flattened with no transparency
- Keep the export in RGB
- Compare the uploaded preview against the source file, because store processing can expose issues that were easy to miss locally
If a screen contains dense UI text, default to PNG first. If file size becomes a problem, test JPEG carefully and inspect the smallest labels before approving it.
One practical rule has saved a lot of last-minute fixes in our submission work. Judge the exported asset in the same state the store will receive it. Figma, Sketch, and Photoshop previews are useful for design review, but they are not the final delivery format.
Common Rejection Pitfalls and How to Avoid Them
Friday release. Assets are approved. The binary is ready. Then App Store Connect rejects one screenshot set because the file for an older device slot is off by a few pixels. That is one of the most common last-mile failures we see at LetsDeployIt, and it catches teams that already checked the flagship sizes.
Reviewers usually are not objecting to your creative direction. They are rejecting avoidable mismatches between the uploaded asset, the selected device class, and the app users will download. The expensive part is that the screenshot can look correct to design, product, and QA, yet still fail because the final exported file does not match the exact slot requirement.
What gets flagged first
The first failure point is exact dimension matching, especially on older, non-flagship device classes. Teams often validate the newest iPhone or a standard Android phone, then assume the resized variants are close enough. Store submission systems do not allow close enough. They check the final pixel dimensions for the slot you selected.
After that, the same trouble spots repeat:
- Wrong device-slot dimensions: Usually caused by resizing from a master file without verifying the exported output for each required class.
- Blurred UI or softened text: Common after upscaling, double compression, or exporting from a presentation layout instead of the native capture.
- Outdated product screens: The listing shows labels, tabs, or feature states that are no longer present in the release candidate.
- Claims the app does not support yet: Promotional copy inside the screenshot promises a workflow or feature the reviewer cannot find.
- Platform inconsistency: iOS screenshots with Android-style framing, system chrome, or visual conventions make the listing look sloppy and invite closer review.
The older-device trap deserves special attention because it creates a false sense of safety. The main screenshots pass internal review, the team signs off, and the rejection only appears at upload. We see that pattern often in multi-device submissions, especially when assets were batch-resized late in the release cycle.
A review-safe checklist
Use a release check that focuses on approval risk, not just design quality:
| Pitfall | Safe rule |
|---|---|
| Invalid dimensions | Verify the exported file against the exact pixel requirement for that slot |
| Blurry exports | Export at final size. Do not upscale store assets |
| Old UI in screenshots | Capture from the current release candidate or the signed-off build branch |
| Promotional promises not present in app | Show only features available in the submitted version |
| Inconsistent orientation or framing | Keep one presentation system for each platform and device category |
A few operating habits prevent most rejects:
- Validate each device class separately. Do not assume a flagship export can be safely reused for older Apple sizes or tablet variants.
- Compare screenshots against the release build, side by side. This catches renamed buttons, missing tabs, and stale onboarding flows.
- Strip test data and sensitive details. Demo names, email addresses, order IDs, and internal environment labels should never reach the store.
- Check overlays and captions against the actual UI. Marketing text often lags behind product changes by a sprint.
- Run a final uploader check before submission. The file that passed design review is not always the file that got attached in App Store Connect or Play Console.
One rule has saved a lot of rework in our deployments. Treat every screenshot as release metadata, not as a design asset. That mindset changes how teams review it, version it, and approve it.
Reviewers only see three things together. The binary, the metadata, and the screenshots. If any one of those tells a different story, the submission becomes harder to approve.
The teams that avoid repeated screenshot rejections usually are not producing fancier artwork. They are running a stricter last-mile process, with special attention to exact dimensions for the older device slots that other guides barely mention.
Automating Screenshots for Faster Submissions
Manual screenshot production breaks once you support multiple devices, localizations, and release branches. It's slow when everything goes right, and it becomes chaos when one asset spec changes late.
Why manual workflows break down
A manual process usually looks manageable at first. Open simulator. Go through a few flows. Save images. Hand them to design. Add overlays. Rename files. Repeat for each locale.
Then one of these happens:
- Product changes a button label.
- Apple rejects one device slot.
- Android tablet screenshots need a different layout.
- A localization overruns the text container.
- The team has to repeat the whole thing during an update submission.
That's why mature teams automate capture wherever they can.
For a visual walkthrough of an automated approach, this video is a useful reference:
A practical automation stack
The most reliable setup combines app test automation with deterministic export rules.
A strong workflow often includes:
- Fastlane for screenshot orchestration and store delivery steps.
- Xcode UI Tests for iOS capture flows.
- AndroidX Test or equivalent for Android capture paths.
- A naming convention that encodes locale, device, and sequence.
- A review layer where someone still checks the final assets before upload.
Here's what that buys you in practice:
- Consistency: Every device captures the same state.
- Repeatability: You can regenerate after UI changes without rebuilding the process.
- Lower human error: Fewer hand-renamed files and ad hoc exports.
- Faster updates: Minor releases stop feeling like mini launch projects.
The mistake is assuming automation means no review. It doesn't. Automation is what produces clean raw material. Human review is what catches the weird edge cases like clipped text, stale seed data, or the wrong onboarding step appearing in one locale.
For React Native and Expo teams, this matters even more because release pipelines already lean on scripted builds, signing, and submission tooling. Screenshot generation should live in that same discipline, not in an ad hoc design folder.
Frequently Asked Questions
Do captions on screenshots matter
Yes. They shape clarity and conversion, but only if they support the actual UI instead of trying to replace it. Keep screenshot text short, legible, and truthful. If the caption promises something the current build doesn't deliver, the screenshot becomes a review risk instead of a marketing asset.
How often should teams check for requirement changes
Check before every meaningful release cycle, not just major launches. Screenshot requirements change less often than APIs, but when they change, they affect asset production, export settings, and sometimes the entire submission checklist. Teams get burned when they rely on a screenshot template that worked a few months ago and assume it's still current.
What about app preview videos
Treat preview videos with the same discipline as screenshots. Match the target device presentation, use current app footage, and make sure the file is aligned with the store's technical rules. The safest approach is to produce videos from the same release candidate used for screenshots so your visuals stay consistent across the listing.
A final practical rule: when in doubt, optimize for accuracy over decoration. Stores tolerate plain screenshots that match the app. They don't tolerate polished assets that misrepresent it.
If you want this handled end to end, LetsDeployIt specializes in getting React Native and Expo apps approved on the Apple App Store and Google Play within 10–14 days. The team prepares screenshot sets for every required device size, store copy, preview assets, compliance items, reviewer notes, and submission handling, then stays with the process through reviewer messages and resubmissions. It's built for teams that want launch-ready store assets without losing another week to preventable submission errors.