App Store 60/40 Screenshot Rule: What Apple Checks

The App Store 60/40 rule, keep about 60% of each screenshot showing real app UI and up to 40% for marketing text and backgrounds, is a community ASO heuristic, not an Apple requirement. Apple's App Store Review Guidelines state no percentage anywhere. The actual rule, Guideline 2.3.3, is qualitative: every screenshot must "show the app in use" [1].

That distinction matters because it changes what you optimize for. You are not trying to hit a pixel ratio that a reviewer measures. You are trying to make sure each frame clearly shows your app doing something, which the 60/40 split happens to be a safe, easy way to guarantee.

This post covers where the 60/40 number comes from, what Apple actually checks, and how to use the heuristic without either over-thinking it or tripping a real rejection.

TL;DR:

• The 60/40 rule (60% app UI, 40% marketing) is a community heuristic. It is not written in Apple's guidelines or screenshot specs [1][2].
• Apple's real rule (Guideline 2.3.3): screenshots must show the app in use, not just title art, a login page, or a splash screen. Text and image overlays are explicitly allowed [1].
• Nothing gets auto-rejected at "59% UI." Rejections come from frames with no real app UI, misleading UI that does not match the app, or pure marketing or splash frames.
• Use 60/40 as a safe default, not a law. Keep real app UI clearly present on every frame, especially the first three.

Table of contents

• What is the App Store 60/40 rule?
• Is the 60/40 rule an actual Apple requirement?
• What does Apple actually check in your screenshots?
• Why does the 60/40 heuristic still work?
• How do you apply 60/40 without getting rejected?
• When can you bend the ratio?

What is the App Store 60/40 rule?

The 60/40 rule is an App Store Optimization convention that says each screenshot should be roughly 60% real app interface and at most 40% marketing layer: headline text, captions, device frames, and background. It is a rule of thumb for keeping your store listing both persuasive and clearly app-focused.

It is popular because it is easy to eyeball. You do not need a tool to see whether more than half a frame is showing your actual product. Designers reach for it as a guardrail so a marketing-heavy concept does not drift into a frame that shows almost no app. The screenshot best practices guide treats it the same way: a sanity check, not a measurement.

Is the 60/40 rule an actual Apple requirement?

No. The 60/40 rule does not appear in the App Store Review Guidelines or the App Store Connect screenshot specifications. Both documents were checked: neither states a 60/40 split, a 60% threshold, or any percentage of UI a screenshot must contain [1][2]. The number is a community invention that operationalizes a rule Apple wrote in plain language.

Here is what Apple actually publishes. Guideline 2.3.3 reads, verbatim: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen. They may also include text and image overlays (e.g. to demonstrate input mechanisms, such as an animated touch point or Apple Pencil) and show extended functionality on device" [1]. The App Store Connect specifications page only sets formats and dimensions: "You must upload one to ten screenshots in .jpeg, .jpg, and .png formats" [2]. There is no ratio.

So when a tool or article tells you "Apple requires 60% UI or you get rejected," that is a misread of 2.3.3. The requirement is real. The number attached to it is not Apple's.

What does Apple actually check in your screenshots?

Apple checks that the screenshot honestly represents the app in use, and that the metadata around it is accurate and appropriate. Reviewers look at whether a frame shows your product working, whether the UI matches the shipped app, and whether overlays cross into misleading territory. Percentage never enters it. The checks are qualitative and per-frame.

The practical line between a clean frame and a rejected one:

Two more guidelines sit alongside 2.3.3. Guideline 2.3 (Accurate Metadata) requires that "screenshots, and previews accurately reflect the app's core experience" [1], which is the misleading-UI trap. Guideline 2.3.8 requires screenshots to keep a 4+ age rating presentation even if the app is rated higher [1]. If you have already been flagged, the screenshot compliance and rejection guide walks the specific causes in order.

Why does the 60/40 heuristic still work?

The 60/40 heuristic works because it is a cheap way to guarantee compliance with 2.3.3 plus good conversion at the same time. If 60% of every frame is real UI, you physically cannot end up with a splash-only or marketing-only screenshot, which is the actual rejection trigger. The ratio buys you a safety margin on a rule that has no margin written into it.

It also lines up with how the store gets browsed. Apple shows the first two to three screenshots in search results, and those frames carry most of the conversion weight, so they need to communicate the product fast. A frame that is mostly your app, topped with a short benefit headline, reads instantly. The first three screenshots playbook covers why those frames earn the most attention. The heuristic nudges you toward UI-forward frames exactly where it pays off.

How do you apply 60/40 without getting rejected?

Apply it as a floor, not a target: make sure every frame shows real, current app UI, keep marketing to the top third or as a frame around the screen, and never ship a frame that is pure background or logo. The ratio is the easy version of "show the app in use." Here is the working checklist:

• Every frame shows the app. Each screenshot should contain a real screen from your shipped build. No splash, login-only, or logo-only frames [1].
• Match the live app. The UI in the screenshot must be what users actually get. Mocked-up features that do not ship are a 2.3 accuracy rejection [1].
• Overlays are allowed, so use them. Headlines, captions, and animated input hints are explicitly permitted by 2.3.3 [1]. The 40% is real estate, not a liability.
• Front-load the first three. Those are the frames Apple shows in search. Make the product obvious there.
• Audit before you submit. Run the set through an ASO audit to catch a frame that drifted marketing-heavy before a reviewer does.

When can you bend the ratio?

You can bend it whenever the full set still shows the app in use, because Apple judges each frame against 2.3.3, not the set against a percentage. A lifestyle or hero frame with light UI is fine as long as it still contains some real app content and the surrounding frames clearly show the product working. The danger is never "this frame is only 45% UI." The danger is a frame with zero app UI at all.

This is where reading the rule as Apple wrote it beats reading the 60/40 number literally. A bold concept frame with a small live UI inset passes, because it shows the app in use. A gorgeous full-bleed lifestyle frame with no app anywhere does not, even if every other frame is 80% UI. Think per-frame presence of real UI, not an aggregate split.

That reframing is the whole point: 60/40 is a useful default that keeps you safe by accident. Once you understand that Apple checks "is the app in use here," you can design with more freedom and still never trip the rule. When you are ready to build the set, the screenshot builder keeps a live device frame in front of you so you can see how much real UI each frame is carrying as you iterate, and the rejection recovery guide covers the fast fix if one slips through.