How Apple's iPad Screenshot Scaling Actually Works (2026)

Apple's iPad screenshot scaling isn't a single downscale. It's a 5-tier cascade: your 2064x2752 upload feeds the 13-inch and 12.9-inch sizes directly, the 11-inch class scales from 13-inch, the 10.5-inch class scales from 12.9-inch (which itself scales from 13-inch), and the legacy 9.7-inch class scales from 10.5-inch [1]. Most ASO guides hand-wave this as "Apple scales it for you." Knowing the actual cascade tells you which iPads get a clean resize and which compound the loss across two or three steps.

TL;DR:

• One iPad upload covers 5 size classes via a chained cascade [1].
• 13-inch (2064x2752) is the source. 12.9-inch and 11-inch scale directly from it.
• 10.5-inch scales from 12.9-inch (already scaled from 13-inch). 9.7-inch scales from 10.5-inch (a third hop).
• Worst-case scale ratio: 13-inch to iPad mini's 11-inch 1488x2266 variant, a 28 percent linear reduction.
• You can override the cascade per device class via Media Manager [2], but almost no app does.
• Generate the 13-inch source at the spec via the iPad Pro mockup generator and the cascade takes care of itself.

This is the technical companion to our iPad Pro 13-inch vs 12.9-inch screenshot specs breakdown (which size to upload). This post covers what happens to that source after upload.

Table of Contents

• What is Apple's iPad screenshot scaling cascade?
• How does the iPad scaling cascade actually work?
• What scale ratio does each iPad get?
• Why does the cascade matter for legacy iPads?
• What gets lost in the downscale?
• How do you design source artwork that survives the downscale?
• When should you upload custom sizes via Media Manager?
• Takeaways

What is Apple's iPad screenshot scaling cascade?

The iPad scaling cascade is App Store Connect's fallback chain that turns one uploaded source into the screenshots shown on every supported iPad. Apple's Screenshot specifications reference [1] lists five iPad display classes (13", 12.9", 11", 10.5", 9.7"), and each class's spec page contains a one-line note about what happens when you don't upload at that size. Stitched together, those notes form a deterministic resize tree.

Apple's exact phrasing on each class [1]:

• 13-inch: "Required if app runs on iPad."
• 12.9-inch: "If screenshots with the accepted sizes aren't provided, scaled screenshots for 13" displays are used."
• 11-inch: "If screenshots with the accepted sizes aren't provided, scaled screenshots for 13" displays are used."
• 10.5-inch: "If screenshots with the accepted sizes aren't provided, scaled screenshots for 12.9" displays are used."
• 9.7-inch: "If screenshots with the accepted sizes aren't provided, scaled screenshots for 10.5" displays are used."

The 10.5-inch and 9.7-inch entries are the ones most ASO posts skip. They don't fall back to 13-inch directly. They fall back to the next-size-up's already-scaled version, which means a chain of resizes for legacy iPads.

How does the iPad scaling cascade actually work?

The cascade is a tree, not a fan. Reading Apple's spec text in dependency order [1], your single 2064x2752 upload feeds 5 size classes through a chain of resizes. The hop count is what matters: each hop runs the resize again and bakes in a new generation of artifacts.

Which iPads land at each tier:

• 13" (direct): iPad Pro M5/M4, iPad Pro 6th/5th/4th/3rd/1st gen, iPad Air M4/M3/M2.
• 12.9" (1 hop): iPad Pro 2nd gen only.
• 11" (1 hop): iPad Pro M5/M4, iPad Pro 4th/3rd/2nd/1st gen, iPad Air M4/M3/M2, iPad Air 5th/4th gen, iPad A16, iPad 10th gen, iPad mini A17 Pro, iPad mini 6th gen.
• 10.5" (2 hops, via 12.9"): iPad Pro 10.5", iPad Air 3rd gen, iPad 9th/8th/7th gen.
• 9.7" (3 hops, via 10.5" and 12.9"): iPad Pro 9.7", iPad Air, iPad Air 2, iPad 6th/5th/4th/3rd gen, iPad mini 5th/4th/3rd/2nd gen.

Two paths do clean single downscales (13" to 12.9" and 13" to 11"). Two paths chain through prior resizes (10.5" through 12.9", and 9.7" through 10.5" through 12.9"). The chained paths are where quality compounds. Each hop runs through whatever resampling filter App Store Connect uses internally, and each hop adds artifacts on top of the previous one.

What scale ratio does each iPad get?

The numbers below are linear-dimension ratios (the percentage of the source's pixel width or height kept after the resize). Area ratios are roughly the square of these.

The cleanest scale is 13-inch to 12.9-inch (99.2 percent linear). It's effectively imperceptible. The next-cleanest is 13-inch to the 11-inch 1668x2420 variant (80.8 percent linear), which is a single resize and stays sharp on most artwork.

The dirtiest scale is 13-inch to the iPad mini A17 Pro's 11-inch 1488x2266 variant. That's a 72 percent linear reduction in one hop, large enough that fine UI elements, kerned headlines, and 1-pixel borders visibly soften. Anything you'd describe as "tight" in the source becomes "fuzzy" on the iPad mini's gallery thumbnail.

Why does the cascade matter for legacy iPads?

Three downscales on the 9.7-inch path is the part that surprises developers. Apple's docs let you read the cascade as one resize per device, but the dependency tree quietly chains them: 13-inch → 12.9-inch → 10.5-inch → 9.7-inch. Each hop runs the resize again. Each hop adds artifacts.

In practice, the 9.7-inch class only matters for apps that still support iPadOS-pre-17 devices: the iPad Pro 9.7" (2016), iPad Air 2 (2014), and iPad 6th gen (2018) and earlier. The iPad mini 5th gen (2019) is the most modern device that lands here. If your app's deployment target is iPadOS 17 or later, you skip this class entirely; those devices can't install your app at all.

For apps that do support those targets (educational apps, kid-focused apps, some utility apps with low system requirements), the 9.7" class is the single worst-quality screenshot rendering iPad users will see. The compound downscale plus the 1536-pixel target (a 74 percent linear scale from the 13-inch source, applied across three resamples) softens text more than any other path in the cascade. If 9.7" matters to your audience, the right move is to upload a custom 9.7" set via Media Manager [2] instead of letting the cascade handle it.

What gets lost in the downscale?

App Store Connect doesn't publish what resampling algorithm it uses [2]. What we know from general image-processing context [3]: the practical choices for high-quality downscaling are bicubic, Mitchell, or Lanczos-family filters. Apple's vImage framework uses Lanczos5 [3], so it's plausible (but unconfirmed) that App Store Connect's server-side pipeline uses something in the same family.

Whatever filter Apple uses, three artifact patterns matter for screenshot artwork:

• Text softening on small UI elements. 12-point text in a 2064-pixel-wide source becomes 8.6-point text after the 72 percent reduction to the iPad mini's 1488-pixel target. Anti-aliasing fills in the rest, but kerning gets fuzzy and hairline strokes lose contrast. The fix is on the design side: never use UI text smaller than 16-18 points in the source artwork if it's part of the screenshot's selling story.
• Aliasing on diagonal lines. Sharp diagonals (chart lines, diagonal dividers, isometric device frames) develop staircase artifacts after a non-integer downscale. The 79.5 percent and 80.8 percent ratios are particularly unkind because they fall between common pixel-grid alignments. The fix: keep diagonal artwork at lower angles (under 30 degrees) where the staircase pattern is less visually disruptive.
• Ringing on high-frequency content. Lanczos-family filters [3] can introduce halos around very sharp edges (text rendered without anti-aliasing, vector logos with crisp outlines). The fix is upstream: render screenshots as PNGs from a tool that already anti-aliases output, not as raw bitmap exports from a 1x source. Pre-anti-aliased input handles the resize gracefully; raw vector edges don't.

The artifact you won't get is color shift. App Store Connect handles sRGB inputs cleanly. The pipeline preserves color profiles even when the underlying resize introduces other artifacts.

How do you design source artwork that survives the downscale?

This is the design rule the sibling post hand-waves and this post nails down. Five choices in the source make the cascade behave:

Render at the largest spec, design for the smallest target. The source must be 2064x2752 to satisfy Apple's upload requirement, but the legibility budget belongs to the iPad mini. Open your finished 13-inch source at 72 percent zoom (matching the 1488x2266 mini target) and verify that headlines, captions, and any UI text remain sharp. If they soften at 72 percent, redesign before uploading. The full validation pass on text legibility is what our caption readability checker automates for the iPhone case; the same principle applies on iPad with looser thresholds.

Use 16-point text minimum for any caption rendered as bitmap text. This keeps caption text legible after the worst-case 72 percent linear scale. Below 16 points, the downscaled glyph occupies fewer than 12 vertical pixels on the iPad mini's gallery, which is the threshold below which Apple's resize visibly hurts.

Avoid fine UI lines below 2 pixels in the source. A 1-pixel border at 2064 pixels wide becomes a sub-pixel line at 1488 pixels wide. The resampler either drops it (line disappears in places) or smears it (line becomes a faint gray bar). Use 2-pixel borders minimum on any UI element that needs to read as a clean edge.

Flatten alpha against your real background. App Store Connect rejects PNGs with transparency [1], and even if it accepted them, the resize would create jagged edges along any soft alpha boundary. Composite your device frame and screenshot against the actual background you want (gradient, solid, photo) before exporting.

Skip 9.7-inch unless you support those devices. If your app's iOS deployment target is iPadOS 17 or higher, the 9.7" class is irrelevant. Don't waste design effort on a path that won't render for any user.

The iPad Pro mockup generator bakes most of these into the export pipeline: 2064x2752 native output, sRGB color, flattened alpha, anti-aliased text rendering. The resize-survival decisions stop being something you have to remember.

When should you upload custom sizes via Media Manager?

Apple's docs include an explicit escape hatch [2]:

"If you prefer not to use scaled versions, you can add specific screenshots and app previews for other device sizes and localizations using Media Manager."

This means you can upload bespoke screenshots per iPad class. The cost is the maintenance overhead: you now have 4 to 5 screenshot sets to keep in sync every time the app's UI updates. For most apps, that's not worth it.

It is worth it for three cases:

Apps that target the 9.7-inch class as a primary audience. Education, kids, and accessibility apps that still ship to iPad mini 5th gen and iPad 6th gen often see most of their iPad installs on those devices. A custom 9.7" set sidesteps the three-hop cascade and gives those users a clean direct render.

Apps where iPad mini conversion specifically matters. Travel apps, transit apps, and reading apps over-index on iPad mini installs. If you can correlate iPad mini conversion to specific screenshot legibility through App Store Analytics, a custom 11-inch 1488x2266 set targeted at iPad mini A17 Pro is a high-leverage swap.

Apps that need orientation-specific sets. Landscape-only apps (some games, some tablet-first productivity apps) often get a quality boost from uploading per-class landscape sets rather than letting the cascade handle a portrait-to-landscape resize.

For everything else, upload one 13-inch set, let the cascade do its job, and move on.

Takeaways

The actionable summary:

• The cascade has 5 tiers and chains through prior resizes. It's not 5 parallel downscales from your source.
• The cleanest paths are 13-inch and 12.9-inch (one hop or zero). 11-inch is one hop. 10.5-inch is two. 9.7-inch is three.
• Worst-case scale is iPad mini's 1488x2266 (72 percent linear, single hop). Test source artwork at 72 percent zoom for legibility.
• 16-point minimum for caption text. 2-pixel minimum for fine UI lines. Below those, the resize hurts.
• Skip the 9.7-inch class entirely unless your deployment target supports those devices.
• Use Media Manager for custom per-device sets only when the cost is justified. Most indie apps don't need it.

For the upstream question of which size to upload in the first place, see the iPad Pro 13-inch vs 12.9-inch screenshot specs breakdown. For the broader compliance and rejection pipeline, the App Store screenshot rejections compliance guide covers the upload-time and review-time failure modes across all device types.

We built Try AppScreenshotStudio today for free so the resize-survival design decisions get baked into the export, not handed to you as homework. Generate the 13-inch source through the iPad Pro mockup generator and the cascade renders cleanly across every iPad your app supports.