Guides

App Store Screenshot Sizes: The 2026 Reference Guide

Makeshots··19 min read

You're probably in the part of the release cycle nobody enjoys. The build is ready, QA is done, the changelog is written, and all that's left is the store listing. Then screenshots become the bottleneck.

That happens because app store screenshot sizes aren't just a design detail. They sit at the intersection of compliance, conversion, localization, and file management. A set that looks perfect in Figma can still fail when you export the wrong device size, use a mismatched frame, or forget that one locale needs a different asset bundle.

Teams usually start by asking for dimensions. That's necessary, but it's not enough. The harder problem is producing screenshot sets that are compliant, persuasive, and easy to update when product copy, UI, or markets change.

Table of Contents

The High Stakes of Getting Screenshot Sizes Wrong

The most frustrating screenshot failures happen at the very end. Product and engineering have already signed off. Marketing has final copy. Someone uploads the listing assets, expects a routine submission, and instead ends up fixing screenshots under deadline pressure.

In practice, screenshot problems fall into two categories. The first is pure compliance: wrong dimensions, wrong file format, or the wrong asset in the wrong device slot. The second is operational: a team has the right raw screens, but they don't have an organized way to generate final store-ready variants for every platform and locale.

That second category causes more delays than anticipated. A small UI change can force a full refresh of the gallery. A copy tweak in one language can create mismatches across the rest. If nobody owns naming, exports, and upload order, review risk goes up fast.

Practical rule: Don't treat screenshots as a last-mile design task. Treat them as release assets with the same rigor you apply to builds, metadata, and QA.

The fix isn't complicated, but it does require discipline. You need a reliable reference for the current requirements, a repeatable production process, and a clear decision about which screenshot sets matter most for each store. Once those are in place, app store screenshot sizes stop being a launch-day hazard and become a routine part of shipping.

Quick Reference for 2026 App Screenshot Sizes

Release teams rarely get blocked by one missing screenshot. They get blocked by the fifth variant, the second tablet crop, and the late copy change that forces every localized set back through export and QA. A quick reference helps, but its main value is using it to reduce rework.

A quick reference chart for 2026 app store and Google Play screenshot dimensions and aspect ratios.

Use the table below as an operational baseline. Apple requires tighter device-class coverage. Google Play gives you more layout freedom, but that freedom creates inconsistency fast if nobody standardizes the source files, aspect ratios, and naming.

2026 App Store Screenshot Sizes Cheat Sheet

Platform Device Class Dimensions (Portrait) Notes
Apple App Store iPhone 6.9-inch 1284 × 2778 Use for the latest large-screen iPhone class
Apple App Store iPhone 6.7-inch / 6.5-inch class 1242 × 2688 Common base size for broad iPhone coverage
Apple App Store iPhone 6.7-inch 1290 × 2796 Current large-format iPhone size used in many release workflows
Apple App Store iPad 12.9-inch class 2048 × 2732 Primary high-resolution iPad screenshot set
Google Play Phone Flexible within store rules Standardize one aspect ratio across the full gallery
Google Play 7-inch Tablet Flexible within store rules Reuse a tablet-safe layout with readable text
Google Play 10-inch Tablet Flexible within store rules Check scaling, margins, and headline length carefully

The table is only the starting point.

For Apple, teams save time by organizing screenshots around a small number of base device buckets instead of exporting every possible device variation by hand. For Google Play, the store is more forgiving on dimensions, but forgiving rules do not fix a messy asset pipeline. Mixed crops, uneven typography, and ad hoc tablet layouts still weaken the listing and create avoidable review prep.

The practical workflow is simple. Keep one master template per platform family, one approved copy source per locale, and one clear export convention for each device class. That is what makes screenshot updates manageable when product ships a UI refresh two days before submission.

Teams that handle screenshots at scale do not win by memorizing dimensions. They win by turning those dimensions into repeatable templates, automated exports, and a QA process that catches wrong-size assets before App Store Connect or Google Play does.

Apple App Store Screenshot Requirements

A common Apple submission failure looks small until release day. The build is ready, metadata is approved, and then App Store Connect rejects the screenshot set because the team exported the wrong device class, mixed orientations without intent, or uploaded assets that do not match the app state in the binary. That kind of mistake costs hours, and in a launch window, hours matter.

Apple's screenshot rules are stricter than Google Play's because Apple organizes assets by device class. You are not uploading a generic phone gallery. You are filling specific slots for specific display groups, and the files need to match Apple's accepted formats and dimensions for those groups.

What Apple requires

For each device class, Apple allows 1 to 10 screenshots in .jpeg, .jpg, or .png. Common working sizes include 1284 × 2778 pixels for the 6.9-inch iPhone class, 1242 × 2688 pixels for the 6.5-inch / 6.7-inch iPhone class, and 2048 × 2732 pixels for the 12.9-inch iPad class.

The practical point is simple. Apple expects the right asset in the right device bucket.

Apple also supports portrait and horizontal screenshots, depending on the app and device class. That helps teams with games, media apps, and iPad productivity products, but it does not reduce review risk. Screenshots still need to reflect the shipped product, use the correct canvas, and look intentional as a set.

How experienced teams handle Apple's device classes

The mistake I see most often is treating every Apple screen size as a separate design project. That creates unnecessary production work and makes localization harder than it needs to be.

A better workflow starts with a small set of master layouts for the main Apple buckets your listing needs to cover. Teams usually build source files for the primary iPhone class and the primary iPad class, then validate scaling and composition before upload. That approach matches how App Store Connect handles screenshot families and keeps the release process manageable when design, copy, and product are all changing late.

This matters even more once localization enters the picture. One English screenshot set is easy. Ten locales across iPhone and iPad classes turns into dozens of exports, filename checks, and upload decisions. Without templates, version control, and automated export rules, screenshot work turns into manual production labor that drifts out of sync with the app.

What holds up in real review workflows

Teams that ship clean Apple listings usually standardize a few operating rules:

  • Lock the sequence before final export: Late reordering often breaks headline logic, feature prioritization, and localization tracking.
  • Separate assets by device class and locale: Clear folder structure prevents wrong-slot uploads in App Store Connect.
  • Design flexible source files: Copy expands in German, contracts in Japanese, and changes until the last minute. Templates need room for that.
  • Check the UI state against the release build: Placeholder data, outdated onboarding screens, and debug badges create avoidable review questions.
  • Review the compressed result, not just the design file: Small text, weak contrast, and crowded layouts often pass design review and fail in the store view.

A lightweight QA pass catches most Apple-side errors before submission:

Checkpoint Why it matters
Correct device-class export Prevents upload mismatches and awkward scaling
Accepted image format Avoids unnecessary submission friction
UI matches the shipped build Reduces review questions and trust issues
Copy fits every locale version Prevents cropped text and rushed redesigns
Sequence approved across teams Stops last-minute changes from breaking the gallery

Apple's rules are manageable once the workflow is disciplined. The hard part is not memorizing dimensions. It is maintaining screenshot sets across device classes, release cycles, and languages without turning every update into a manual cleanup project. That is where automation saves time, keeps naming and exports consistent, and prevents costly submission mistakes.

Google Play Store Screenshot Requirements

Google Play is easier to work with than Apple on raw dimensions, but that doesn't mean teams can be casual. Flexibility helps with asset generation. It also creates room for inconsistent galleries, stretched exports, and weak visual hierarchy.

Where Google Play is flexible

Google Play requires 2–8 screenshots per device type, with dimensions between 320 px and 3840 px on the longest side. The maximum dimension also can't exceed twice the minimum dimension. If you include a promo video, you also need a 1024 × 500 px Feature Graphic, as summarized in AppTweak's Google Play screenshot guidelines.

That set of rules gives Android teams more room to choose a visual system that matches their app. You can work with phone and tablet layouts without fitting into Apple's device-class structure. The upside is speed. The downside is that many teams use the flexibility badly.

A good Google Play gallery still needs internal consistency. Aspect ratios should feel deliberate. Typography should look like part of one campaign. Screens should read as one story, not as a folder of unrelated exports.

What trips teams up anyway

Most Google Play mistakes come from design choices, not from the store limits themselves.

  • Overly mixed aspect ratios: Technically acceptable assets can still look chaotic when users swipe through them.
  • Weak feature graphic handling: If your listing includes a promo video, the feature graphic becomes part of the presentation system, not an afterthought.
  • Tablet neglect: Teams often build a decent phone set and then stretch the same thinking onto larger canvases where spacing and text balance break down.

A permissive platform doesn't remove the need for standards. It makes your internal standards more important.

One workflow that holds up well is to define a house style for Android first. Pick a background treatment, text placement system, and device framing approach, then apply it across phone and tablet families. That gives your gallery cohesion even when the underlying screen sizes vary.

Google Play also benefits from cleaner production files than people expect. If the screenshots are full of tiny callouts, decorative clutter, or uneven margins, the listing starts to look like ad creative instead of product marketing.

Universal Rules and Strategic Best Practices

Teams rarely get rejected because they forgot a pixel dimension. They lose performance because the gallery is hard to scan, the message changes from frame to frame, or the production process breaks under release pressure.

An infographic detailing essential do's and don'ts for designing effective and professional mobile app store screenshots.

Choose orientation deliberately

Orientation is a product marketing decision first, and a design decision second.

Portrait usually gives consumer apps the best result because it matches how people browse the store and leaves room for a readable headline above the UI. A horizontal presentation works for games, video products, and flows where width carries the story. If the app is used in portrait but the listing is presented horizontally, teams usually pay for that mismatch with weaker comprehension.

Consistency matters just as much. Once you choose an orientation for a screenshot set, keep the visual system stable across every panel, locale, and device family unless there is a clear merchandising reason to change it.

Treat sequence as a conversion path

The gallery should answer a simple question at each step: why install this app, why trust it, and why keep swiping?

A sequence that works in practice usually follows this pattern:

  • Lead with the main outcome: Show the result users want, not a feature menu.
  • Use the second and third frames to remove doubt: Highlight the clearest proof points, core workflow, or differentiator.
  • Give each screenshot one job: One benefit, one message, one visual focal point.
  • Reserve detail for later panels: Deep features belong after the value proposition is already clear.

This structure also makes revision cycles faster. When product marketing changes one claim, the team can update one panel instead of rewriting the whole set.

Design for scale, not for one launch

A screenshot system should survive more than the next release. It needs to hold up across new devices, app updates, seasonal campaigns, and localization rounds.

That changes how strong teams build assets. They use reusable text styles, fixed safe areas, repeatable device framing, and naming rules that make exports easy to validate. Manual one-off compositions often look fine in Figma and then turn into rework when legal copy changes or five new languages need the same layout by Friday.

If you're aligning the rest of the listing at the same time, the Makeshots app icon generator helps keep icon treatment consistent with the screenshot system.

Keep production quality high

Clean production choices prevent avoidable review issues and weak storefront presentation.

Use PNG when UI detail needs to stay sharp. Use JPEG only when the artwork is more photographic and compression will not soften small interface elements. Check final exports at real storefront sizes before upload. Tiny text, low-contrast captions, and crowded callouts often pass an internal review and still fail in the store because they are unreadable on a phone.

Strong screenshot sets usually feel simple because the team imposed constraints early. Fixed typography. Fixed spacing. Fixed message hierarchy. Those rules save time, reduce drift across markets, and make every update easier to ship.

The Real Challenge Beyond Pixel Dimensions

A team can know every required screenshot size and still miss a release window.

The work that slows app teams down happens after the dimensions are settled. Someone updates a paywall screen two days before submission. Legal changes a disclaimer in three languages. A country manager wants different value props for Japan and Germany. Now the job is no longer "make screenshots." It is version control, localization, QA, and store-ready export management.

A process flow chart illustrating the five steps of managing and updating mobile app store screenshots.

Localization turns a small design task into production work

One approved concept quickly becomes dozens of assets. Each locale can require new headlines, different line lengths, different legal text, and occasional message changes based on market positioning. Add phone and tablet sets, then multiply again for seasonal campaigns or feature refreshes.

The failures are usually operational, not creative.

  • Naming breaks down: exported files do not clearly map to locale, device, or store slot.
  • Copy drifts: one market gets the revised headline while another keeps last month's text.
  • Product screens go stale: the UI changed, but only part of the screenshot set was regenerated.
  • Upload errors slip through: final assets exist, but the wrong files get attached to the wrong listing.

I have seen teams spend more time checking folders and filenames than reviewing the actual storefront story. That is a process problem, not a design problem.

Manual handling fails under release pressure

A manual workflow can survive an initial launch. It usually starts to fail during the second or third update cycle, when requests arrive from multiple directions at once. Product wants the latest UI. Marketing wants a campaign variant. Localization needs new exports. App review deadlines do not move.

At that point, every hand-built file becomes a liability. A designer re-exports one screen but misses the tablet version. A marketer duplicates a folder and carries over old copy. Someone uploads an outdated set because the latest assets were saved under a slightly different naming convention.

The cost shows up in rework, review delays, and inconsistent listings across markets.

Teams that handle this well treat screenshots like a repeatable content system. Source screens stay organized. Copy lives in structured fields, not baked into one-off files. Device frames, layouts, and export rules are standardized. A tool like the Makeshots screenshot generator helps by turning one approved system into consistent store-ready outputs instead of forcing the team to rebuild each variation by hand.

That shift matters once screenshots become recurring operational work. Creative direction still needs judgment. Assembly, resizing, localization, and export hygiene should be handled with far less manual effort.

How to Automate Your Screenshot Workflow

Automation matters when your screenshot process becomes recurring operational work instead of a one-time launch exercise.

Screenshot of the Makeshots browser-based screenshot generator.

The goal isn't to remove judgment. You still need to decide the story, the order, the headline style, and the visual tone. Automation removes the repetitive assembly work: placing screens into device frames, generating store-sized outputs, organizing exports, and keeping locale variants aligned.

Build one system, not one-off files

A reliable screenshot workflow usually has four stages.

First, capture clean source screens from the app in stable UI states. Don't start with heavily composited PSDs if the product is still changing.

Second, define a reusable layout system. That includes your device framing, text placement, spacing, background treatment, and per-platform variants.

Third, generate localized and device-specific outputs from that system instead of redesigning each panel separately. Tools in this category vary, but the useful ones all solve the same problem: one source set should become many compliant export sets with minimal manual intervention. One browser-based option is the Makeshots screenshot generator, which creates store-ready outputs for Apple and Google Play, organizes exports, and supports localized panel copy.

Fourth, review the final listing view before upload. That step catches issues that are easy to miss in design software, especially text scale and sequencing.

What an automated workflow should output

The output matters as much as the editor. If the end result still requires manual cleanup, you haven't solved the core bottleneck.

Look for a system that produces:

  • Correctly sized exports for each target store
  • Consistent device framing and composition
  • Editable panel copy that can be updated without redesigning layouts
  • Locale-specific folder structure for upload
  • Preview modes that resemble the final listing experience

A short product walkthrough makes the difference clear in practice:

When this is done well, screenshot production stops blocking releases. Product can update the message. Marketing can test new positioning. Design can maintain quality without hand-touching every export. That's the shift many teams need.

Common Screenshot Pitfalls to Avoid

Most screenshot mistakes aren't complex. They're preventable.

  • Using non-final UI: Wireframes, placeholders, debug states, and unfinished screens weaken trust fast. Use real product UI from a controlled build.
  • Writing text nobody can read: Thin fonts, low contrast, and long captions fail on mobile screens. If the message isn't readable at a glance, shorten it.
  • Mixing visual systems: Different background styles, inconsistent framing, and random text placement make the gallery feel stitched together.
  • Forgetting store context: A screenshot can look polished in a design file and still feel cramped when viewed inside a store listing.
  • Uploading disorganized assets: Even strong designs fail operationally when filenames, locale bundles, or device folders are messy.

A simple rule helps here. If someone outside the project can't tell which screenshot goes first, what feature it sells, and which store slot it belongs to, the set isn't ready.

Frequently Asked Questions About App Screenshots

Can you reuse iPhone screenshots for iPad submissions?

Not directly as a blanket rule. Apple uses device classes, so iPad screenshots should be prepared for iPad contexts rather than treated as stretched phone assets. Reuse the visual system, not the exact file.

Do screenshot size requirements change often?

They do change over time. That's why teams should check the current store documentation before each major release or listing refresh instead of relying on an old template library.

Are dimensions the hardest part?

Usually not. The harder part is keeping copy, locales, layouts, and exports synchronized once the app changes.

What about Apple Watch, Apple TV, or Mac listings?

Those need their own store assets and should be handled as separate listing workstreams. Don't assume a phone-first screenshot process will cover them cleanly.

How do you keep metadata and screenshots aligned?

Use the same review pass for both. If you're tightening titles and subtitles at the same time, a utility like the Makeshots ASO character counter can help keep text constraints visible while you finalize the gallery.

If your team is spending more time resizing, renaming, and localizing screenshots than deciding what the listing should say, Makeshots is built for that exact workflow. It turns raw app screens into store-ready screenshot sets for Apple App Store and Google Play, with localization, previews, and organized exports that are easier to upload and maintain.

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