App Store Screenshot Requirements 2026: Ultimate Guide
You're probably here because the app itself is ready, but the store listing isn't. Engineering is done. QA is mostly done. Then the release stalls because screenshots don't match the store's rules, the wrong locale got uploaded, or someone exported beautiful marketing images that a reviewer sees as misleading.
That's why app store screenshot requirements aren't just a design checklist. They sit at the intersection of store compliance, product storytelling, and operational discipline. If your process is loose, screenshots become the last fragile step before launch. If your process is repeatable, they become a reliable part of every release.
Table of Contents
- Why Your App Submission Just Got Rejected
- Apple App Store vs Google Play Screenshot Rules at a Glance
- Apple App Store Screenshot Specifications
- Google Play Store Screenshot Guidelines
- Beyond Dimensions Common Rejection Reasons
- Designing Screenshots That Actually Convert
- Managing Localization and Multiple Devices Efficiently
- How to Automate Screenshot Production in Minutes
- Frequently Asked Questions About App Screenshots
Why Your App Submission Just Got Rejected
The most common screenshot failure happens late. A team spends weeks polishing onboarding, payments, notifications, and analytics, then loses time on something that looked simple: image uploads. The listing goes into review, and the problem isn't the code. It's that a screenshot doesn't match the required device class, doesn't reflect the actual UI, or contains marketing treatment that crosses the line into misrepresentation.
I've seen this hit careful teams, not sloppy ones. The pattern is usually the same. Someone designs screenshots in Figma, someone else exports them, another person localizes copy in a spreadsheet, and the final uploader assumes the files are interchangeable between stores. They aren't.
Practical rule: Treat screenshots like release assets, not campaign extras.
That mindset matters because the stores use screenshots for two jobs at once. They help users evaluate the product, and they help the platform enforce trust. If the screenshots imply features the app doesn't offer, hide the actual interface, or fail technical validation, your launch can stop right there.
A rejection tied to screenshots is frustrating because it feels avoidable. It usually is. The fix isn't just memorizing size rules. The fix is building a workflow that accounts for review standards, device-specific exports, and localization before submission day.
Apple App Store vs Google Play Screenshot Rules at a Glance
A screenshot set can pass internal review, look polished in Figma, and still fail at upload because Apple and Google evaluate different things. Apple treats screenshots as device-specific listing assets. Google gives you more flexibility on dimensions, but it is stricter about count limits, aspect ratio, and file validation. That difference changes how teams should produce assets, not just how they export them.
| Requirement | Apple App Store | Google Play Store |
|---|---|---|
| Screenshot count | 1 to 10 screenshots per app listing | 2 to 8 phone screenshots |
| Dimension philosophy | Exact device-specific sizes by device class | Flexible dimensions within defined pixel and aspect-ratio limits |
| File formats | .jpeg, .jpg, .png | JPEG or 24-bit PNG |
| Review emphasis | Match the real app experience for the target device and storefront | Show the app clearly and avoid misleading presentation |
| Operational burden | Version control across device classes, display variants, and languages | Export discipline across count limits, aspect ratio, and file size checks |
The practical problem is operational, not theoretical. Apple usually creates more work for teams supporting multiple device classes and storefront languages. Google usually creates fewer size variants, but mistakes still happen when teams reuse Apple assets without checking crop safety, count limits, or export settings.
This is why one shared master set rarely holds up in production. A repeatable workflow works better: define store-specific templates, lock copy length early, and validate outputs before submission. If your team needs a starting point for device mappings, keep an App Store screenshot sizes reference close to the design file so production does not turn into last-minute resizing.
The shortcut is simple. Treat screenshots as release operations involving compliance, design, and localization, not as final marketing art exported the night before launch.
Apple App Store Screenshot Specifications
Apple screenshot prep usually breaks down late in the release cycle, not because the rules are hard to read, but because the work spans product, design, QA, and localization. A set that looked finished on the design board can still fail at upload if the wrong device variant, language version, or file export slips in.
Apple's official requirements
For App Store listings, Apple allows between 1 and 10 screenshots per supported device class. Accepted formats are .jpeg, .jpg, and .png. The files also need to match Apple's device-specific screenshot slots for the platforms and display families your app supports, as noted earlier.
The detail that matters in practice is not the screenshot count. It is the matrix behind the count. If the app ships on iPhone and iPad, and the listing is localized into several storefront languages, the asset set grows fast. One marketing narrative turns into many production files, and each one has to stay accurate to the in-app experience.
Apple is also strict about representation. Screenshots should show the actual product for the target device, with UI that matches what users and reviewers will see. Over-styled mockups, stretched interfaces, outdated onboarding flows, and promotional art that hides the product are all common ways to create review risk.
Where production usually slows down
The first failure point is late resizing. Teams approve a polished iPhone set, then try to force it into other classes near submission. That creates copy overflow, bad crops, inconsistent spacing, and preventable localization edits.
The second failure point is asset ownership.
Marketing often owns headlines. Product decides feature order. Design handles layout. Release or growth teams upload files. Without one person checking the full chain, the team ends up with mismatched exports, missing language sets, or screenshots captured from the wrong build.
A workflow that holds up under release pressure is usually simple:
- Capture from release-ready builds: Avoid demo-only states, old UI, or data that will not appear in production.
- Design per device family: Start with the target frame and hierarchy for that class instead of adapting one generic canvas later.
- Freeze copy before translation starts: Small headline changes multiply quickly across languages and device variants.
- Run a pre-upload check: Confirm file format, slot coverage, language mapping, and visual accuracy before anyone touches App Store Connect.
For day-to-day production, keep a current App Store screenshot size reference for Apple device classes next to the working file. That saves time during export planning and reduces last-minute guessing about which layouts need their own source design.
Teams that treat screenshot specs as an export task usually burn time at the end. Teams that treat them as a release workflow catch problems earlier, ship cleaner assets, and avoid avoidable submission delays.
Google Play Store Screenshot Guidelines
A Google Play listing often gets assembled late. The build is ready, launch copy is half-approved, design exports one phone size, and someone assumes Google will accept whatever fits inside a broad dimension range. That is where teams lose hours. Google Play gives you more flexibility than Apple on canvas size, but that flexibility shifts the burden to your workflow. You still need assets that are compliant, visually consistent, and ready for every market you plan to ship.
The core technical rules
For phone listings, Google Play requires at least 2 screenshots and allows up to 8. Accepted formats are JPEG and 24-bit PNG. Each file must stay under 8 MB, and the image dimensions must fall within Google Play's allowed range with no side longer than twice the shorter side.
Those rules sound simple. The operational part is harder.
Google is less prescriptive about exact device classes, so teams often skip standardization and export ad hoc assets from whatever source file is handy. That usually creates avoidable problems: copy that wraps differently between languages, screenshots that mix aspect ratios, and galleries that look like they came from three separate release cycles.
What Google's flexibility actually changes
Apple forces a device-based submission matrix. Google Play gives you a range-based system. That reduces export volume, but it also removes guardrails. If your team does not define its own production standard, the listing quality drops fast.
In practice, I recommend picking one base ratio for phone screenshots per release, locking headline lengths before localization starts, and treating the full screenshot set as a marketing sequence, not a folder of miscellaneous app captures. The first three panels do most of the work. If those frames are unclear, the rest of the gallery rarely saves the listing.
The common failure patterns on Google Play are operational, not just visual:
Near-duplicate screens The gallery repeats one flow with minor UI changes instead of showing distinct user value.
Text-heavy creative that breaks in localization English may fit. German, French, or Japanese often exposes weak layout decisions immediately.
Loose export standards One screenshot has a status bar, another hides it. Padding shifts. Device framing changes. Review may still pass, but conversion usually suffers.
Assets pulled from the wrong build This is a frequent release-week mistake. The screenshots are technically valid and still wrong for the version under review.
A better way to handle Google Play assets
The teams that move fastest on Google Play are rarely the ones designing screenshots one by one. They use a repeatable system. Product signs off on feature order. Marketing locks the message. Design works from reusable templates sized to the chosen ratio. Localization works from frozen copy, not screenshots that are still changing.
That process matters because Google Play's flexibility can help or hurt. Used well, it reduces production time across devices. Used poorly, it creates inconsistent galleries, last-minute re-exports, and preventable submission delays.
Your Google Play gallery should read like an edited story with clear production rules behind it. That is how you keep compliance, design quality, and localization from colliding right before launch.
Beyond Dimensions Common Rejection Reasons
Stores don't reject screenshots only because of sizes and formats. A screenshot set can pass technical validation and still create review trouble if it misrepresents the app, shows the wrong experience, or creates confusion about what the user will get.
Misleading presentation gets flagged fast
The basic standard is honesty. If the screenshot suggests a feature that isn't in the app, review can turn into a back-and-forth you didn't budget for. The same applies when the screenshots show an old interface while the build contains a newer one.
Common trouble spots include:
- Overstated feature claims: The caption promises an outcome or capability the product does not deliver in the submitted build.
- Decorative mockups that hide the interface: Reviewers need to see the app, not just a lifestyle concept around it.
- Composited screens that never exist in product: If users can't reach that state, don't present it like a real screen.
- Third-party marks or brand elements: If a logo or partner visual appears without a clear reason or permission, you're inviting questions.
Reviewers are checking trust signals
Reviewers aren't only checking whether the screenshots look attractive. They're checking whether the listing helps users make an accurate decision. That's why small details matter so much: visible personal data, fake notifications, outdated pricing, or UI that doesn't match the device context can all raise issues.
A practical QA pass before upload should include:
| Check | What to look for |
|---|---|
| UI match | Screenshots reflect the submitted build |
| Content accuracy | Claims align with what users can do in the app |
| Privacy hygiene | No personal data, private messages, or real user details visible |
| Brand safety | Only use logos, names, and marks you're allowed to show |
Teams often focus on visual polish and skip review realism. That's backwards. The first job of a screenshot is to be believable.
Designing Screenshots That Actually Convert
Approval gets you listed. It doesn't get you installed. The stores are full of apps with compliant screenshots that still fail to persuade because they don't explain the value of the product quickly enough.
Lead with the job your app helps users do
Most weak galleries start with internal thinking. "Dashboard." "Analytics." "Smart tools." That language describes software components, not user outcomes. Stronger galleries start with the task the user wants completed and then support that claim with a relevant screen.
A useful pattern is to write each panel headline as a user-facing promise, then choose the screen that proves it. If the sentence and the UI don't reinforce each other, one of them is wrong.
Good screenshot copy usually has these traits:
- Short enough to scan quickly: Users shouldn't need to read a paragraph.
- Specific enough to mean something: "Stay organized" is weaker than language tied to a visible workflow.
- Matched to the actual screen shown: The claim and the image should feel inseparable.
Design rule: If a user can crop away the screen and the caption still reads like generic marketing, the panel isn't doing enough work.
Treat the gallery like a sequence not a poster
A screenshot set should unfold logically. The first panel earns attention. The next few panels explain the product. Later panels can handle edge features, proof points, or deeper workflows.
What usually works:
- Open with the clearest value proposition.
- Follow with the core flow users care about.
- Add supporting features only after the main story is clear.
- End with something that broadens appeal, such as flexibility, customization, or cross-device usage if relevant.
What usually doesn't work is repeating the same visual treatment across every panel with only the headline changed. Users don't experience that as a story. They experience it as noise.
Localization matters here too. Translating text isn't enough if the message relies on idioms, cramped copy, or region-specific assumptions. The screenshot set still needs to read naturally in each market.
Managing Localization and Multiple Devices Efficiently
The screenshot problem gets harder when the app grows. A single-language phone app can survive on a manual process for a while. A multi-locale app that runs across device classes usually can't.
The asset matrix grows quietly
Apple's upload model is where many teams feel the pain first. If an app runs on iPhone and iPad, screenshots are required for both device classes, and each localization has its own screenshot set in App Store Connect, as explained in Apple's upload guidance for app previews and screenshots.
That's the point where screenshot work stops being a design task and becomes an operations task. One approved screen flow can turn into a full matrix of assets across devices and languages. Then come the familiar problems: inconsistent naming, wrong folder structure, stale copy in one locale, and last-minute fixes that only make it into half the exports.
Build a system before launch pressure hits
The teams that handle this well usually standardize a few things early:
- Master screen selection: Decide which in-app states represent the product, and freeze them for the release cycle.
- Copy version control: Keep screenshot headlines in one owned source, not across scattered files.
- Export conventions: Use predictable naming by store, device class, and locale.
- Final review ownership: One person approves the upload package as a release asset.
If your team also manages listing text, a simple ASO character counter helps keep adjacent metadata under control so screenshots and copy don't drift apart during localization.
The key shift is mental. Don't ask, "How do we make screenshots?" Ask, "How do we produce screenshot sets repeatedly without introducing release risk?"
How to Automate Screenshot Production in Minutes
Once you've launched enough apps, the pattern is obvious. Manual screenshot production doesn't break because people are careless. It breaks because the process asks humans to repeat too many precision tasks under deadline.
A practical workflow that scales
The cleanest setup is to separate the work into three layers:
Source screens Capture app UI from stable builds.
Narrative layer Choose the order, captions, and visual emphasis for each panel.
Store-specific export Generate the final outputs for each platform, device class, and locale.
That last layer is where automation pays off. Instead of resizing by hand, renaming files manually, and duplicating layouts across languages, teams can use tools that preserve the original UI while handling repeated production work. One option is the Makeshots screenshot generator, which creates store-ready screenshot sets, supports localization workflows, and exports assets structured for upload.
The point isn't that every team needs the same tool. The point is that every serious team eventually needs the same capability: consistent output without repetitive manual handling.
What to automate and what to review manually
Automation is ideal for resizing, folder organization, layout consistency, and first-pass copy generation. Humans should still review the parts that affect trust and positioning.
Keep manual review focused on:
- Feature order: The gallery should match what matters most to the target audience.
- Headline quality: Generated copy often needs tightening.
- Locale review: Translated text must fit the design and sound natural.
- Submission QA: Final exports still need a release check before upload.
A quick product walkthrough helps make that workflow more concrete:
When teams automate the mechanical parts and reserve human attention for strategy, screenshot production stops being the launch bottleneck.
Frequently Asked Questions About App Screenshots
Can I use mockups instead of real UI
Use the actual UI as the foundation. Decorative framing can help readability, but the screenshot still needs to represent the actual app experience. If the treatment hides the product or implies an interface that doesn't exist, you're creating review risk.
Do screenshots need updates every release
Not every release. But they should be updated whenever the screenshots no longer reflect the current product, positioning, or key flows. If the first-run experience changes, a major feature ships, or the visual design shifts materially, old screenshots can hurt both trust and conversion.
Are app previews reviewed differently from screenshots
They're different assets, but the same principle applies. The preview and the screenshot gallery both need to match the actual product experience and avoid misleading presentation. Teams often make the mistake of treating video as pure promotion. Review doesn't see it that way.
Should the same screenshot order be used in every country
Usually not. The structure can stay similar, but copy length, messaging emphasis, and even feature order may need adjustment by market. Localization works best when it adapts the message, not just the words.
What's the biggest process mistake teams make
They wait too long. Screenshots get treated as the final art task after development is done, when they should be planned as part of release operations from the start.
If screenshot production is slowing launches, Makeshots is worth a look. It's a browser-based tool for turning raw app screens into store-ready Apple App Store and Google Play screenshot sets with localized copy, previews, and export folders structured for upload.
Make store-ready visuals in minutes
Turn your raw app screens into a polished, upload-ready screenshot set with Makeshots — no designer required.
Create screenshots