A subscription tier comparison frame in App Store screenshots works when feature differentiation IS the conversion barrier (productivity apps with substantive free tiers, utility apps with capability gates, health-tracking apps with metric tiers). It fails when one transformative feature should fill the slot (meditation, dating, single-purpose games). Apple Review Guideline 2.3.7 bans prices and trial duration inside screenshots [1], so the comparison must show capability gates ("Pro unlocks scheduling"), never pricing differentials.
Most subscription-app screenshot guides treat the tier-comparison frame as a default. Show your tiers, list the Pro features, sell the upgrade. That instinct comes from in-app paywall design, where multi-tier displays are the norm. The App Store screenshot surface is a different design problem: Apple's metadata rules ban pricing text, scroll depth caps the slot count at 5 effective frames, and the conversion job is to get the browser to install at all, not to pick a tier.
This is written for the solo indie developer shipping a subscription app, deciding once whether to spend one of the five screenshot slots on a tier comparison.
TL;DR:
- Multi-tier comparison frame works when feature differentiation IS the conversion barrier. It fails when one transformative feature defines the app.
- Apple Review Guideline 2.3.7 bans prices and trial terms in screenshots [1]. Comparison frames must show capabilities ("Pro unlocks scheduling"), not pricing differentials.
- RevenueCat 2026 case studies: paywalls that went from 3 visible tiers to 2 gained +17% ARPU, +31% install-to-trial, and +72% install-to-trial across three separate apps [4]. The "simpler beats complex" pattern transfers to screenshot frames.
- Belongs in frame 3 of the 5-frame sequence, not frame 1 (outcome hook) or frame 5 (paywall echo).
- Productivity, utility, health-tracking earn the slot. Meditation, dating, single-purpose games skip it.
Table of Contents
- Why do most subscription apps skip the tier comparison frame?
- What does Apple Review Guideline 2.3.7 allow in a tier comparison frame?
- Which categories earn the tier comparison frame slot?
- Where should a tier comparison frame land in the 5-frame sequence?
- How does RevenueCat's 2026 paywall data shape the screenshot decision?
- What anti-patterns kill tier comparison frame conversion?
Why do most subscription apps skip the tier comparison frame?
Most subscription apps skip the tier comparison frame because the default screenshot playbook is "show value," not "show structure." The 5-frame pre-sell sequence reads outcome → transformation → signature feature → trust → paywall echo. None of those slots are obviously labelled "show your tiers." So the comparison frame either replaces frame 3 (signature feature) or doesn't ship at all.
The skip is correct for most apps. A meditation app sells "fall asleep in 8 minutes." A dating app sells "match with someone real this week." A puzzle game sells "this level you can't stop playing." For those products, the conversion barrier is whether the user believes the outcome happens, not whether they understand which tier delivers which feature. Burning frame 3 on a Free vs Pro grid trades the outcome demonstration for a structural decision the user hasn't asked about yet.
The skip is wrong for a different class of app. A productivity tool with a substantive free tier and a Pro tier that unlocks scheduling, collaboration, or unlimited projects has a real conversion question: "what do I get for paying?" A utility app where the free tier is capability-limited (transcription minutes per month, scans per day, exports per week) has the same question. A health-tracking app where the free tier tracks one metric and the Pro tier adds the rest sits in the same shape.
For these apps, frame 3 doing single-feature demonstration is the waste. The user already knows what the feature does. What they don't know is which tier gives them enough of it. The tier comparison frame answers that question inside the App Store listing instead of pushing it to the paywall.
What does Apple Review Guideline 2.3.7 allow in a tier comparison frame?
Apple Review Guideline 2.3.7 allows capability labels and feature lists; it bans pricing text, trial duration, and any descriptor that's not specific to the metadata type [1]. The compliance-safe pattern for a tier comparison frame is two columns of capability checkmarks under "Free" and "Pro" labels, no dollar amounts, no "Save 30%" overlays, no "7-day free trial" line.
Section 2.3.7 reads, "Metadata such as app names, subtitles, screenshots, and previews should not include prices, terms, or descriptions that are not specific to the metadata type" [1]. Section 2.3.2 separately requires that screenshots clearly indicate when features require additional purchases [1]. The combined effect on a tier comparison frame: you must signal that some features are paid, you cannot show what they cost, and you have to do both inside a single visual that the user reads in under a second.
The patterns that pass review are narrow:
- Two-column capability matrix. Left column "Free", right column "Pro" (or "Plus", "Premium", whatever your product calls it). Each row is a capability ("Unlimited projects", "Calendar sync", "Team sharing"). Checkmarks under the relevant column. No prices, no durations.
- Capability-gated screen mockup. Show the actual product screen with a "Pro" badge on the feature that's gated. The badge is text, not a price.
- Tier-named feature callout. A specific Pro-tier capability shown in use, with a "Pro" or "Premium" label visible in the UI itself (because the actual app shows that label, not the screenshot manufacturing it).
The patterns that get flagged are equally narrow. Any frame that includes a price ("$9.99/mo"), a trial duration ("7-day free trial"), a discount overlay ("Save 50%"), or implies pricing through visual hierarchy ("Best value!" with star burst over the annual column) sits in the rejection zone. The App Store screenshot rejection process can stall your release on metadata-rule failures, which costs days not minutes. The compliance constraint is the design constraint.
Which categories earn the tier comparison frame slot?
Six categories cluster cleanly: productivity, utility, and health-tracking earn the tier comparison slot because feature differentiation IS the conversion barrier. Meditation, dating, and single-purpose games skip it because one transformative outcome should fill the slot instead. The decision tracks whether the user's pre-install question is "what tier do I need?" or "does this app deliver the outcome?"
The per-category read:
| Category | Pre-install user question | Comparison frame earns slot? | Recommended pattern |
|---|---|---|---|
| Productivity (note-taking, project mgmt, calendars) | "Which tier do I need for my workflow?" | Yes | Two-column capability matrix |
| Utility (transcription, scanning, file conversion) | "How much do I get on free? When do I need Pro?" | Yes | Capability-gated screen mockup with quotas labelled |
| Health-tracking (calorie, sleep, workouts, mood) | "Which metrics are free and which are Pro?" | Yes | Two-column capability matrix |
| Meditation, sleep, calm | "Does this actually help me sleep?" | No | Outcome demonstration (frame 3 stays signature feature) |
| Dating | "Are there real people I'd match with?" | No | Profile gallery (frame 3 stays signature feature) |
| Single-purpose games | "Is this game fun?" | No | Gameplay screen (frame 3 stays signature feature) |
The categories that earn the slot share a structural property: their free tier delivers genuine value, AND their Pro tier adds capabilities the free user can predict they'll want. Notion's Free / Plus / Business / Enterprise tier ladder maps to personal vs team needs; users want to see which tier matches their use case before installing [5]. Canva's Free → Pro → Teams structure does the same thing. The comparison frame is doing the work the paywall would otherwise have to do alone.
The categories that skip the slot share the inverse property: their conversion question is "does the app work" before it's "which tier do I need." A user evaluating a sleep app doesn't ask which tier unlocks deep-sleep tracking; they ask whether the app helps them sleep. Frame 3 demonstrating the sleep mechanism is doing more conversion work than a tier matrix would. The vertical-specific design patterns for productivity differ from the patterns for wellness for exactly this reason.
For finance and fintech apps, the picture is mixed. Budgeting tools with substantive free tiers (Copilot, Monarch tier ladders) earn the slot. Single-purpose tax apps usually skip it. The trust-first framing in finance screenshots often beats a tier matrix even when a tier ladder exists.
Where should a tier comparison frame land in the 5-frame sequence?
A tier comparison frame belongs in frame 3 of the 5-frame sequence, the position normally reserved for the signature feature running live. Frame 1 (outcome hook) and frame 5 (paywall echo) are wrong because frame 1 has to establish the outcome before any structural question makes sense, and frame 5 has to mirror the paywall headline. Only about 11% of users reach frame 5 on portrait layouts [4], so structural decisions in frame 3 see roughly 4x the audience.
Frame 1 should always be the outcome the user gets. "Plan your whole quarter in one view." "Transcribe a 60-minute meeting in 90 seconds." "Track every metric your doctor asks about." Putting a Free vs Pro grid in frame 1 wastes the highest-conversion slot on internal structure instead of external value. A user who hasn't decided the outcome matters won't be moved by "Pro unlocks more of it." The first three frames carry roughly 70% of conversion weight; spending frame 1 on tiers leaks that weight.
Frame 3 is the right slot for two reasons. First, it sits inside the high-attention window (about 35-40% of users still reach frame 3 on portrait). Second, the question it answers ("which tier do I need?") is downstream of the questions frames 1 and 2 already answered ("what's the outcome?", "does it actually happen?"). By the time a user reaches frame 3, they've internalized the value and are now sizing up the structure.
Frame 5 is wrong for a tier comparison because the paywall echo principle requires frame 5 to visually mirror the paywall's top promise. The paywall says "Get unlimited workouts"; frame 5 should show unlimited workouts stacking up, not a Free vs Pro grid. The paywall echo principle collapses if frame 5 introduces a new structural concept the paywall doesn't carry forward.
The slot decision compounds with the trial-messaging decision. If you ship a tier comparison in frame 3, the trial-messaging pattern in frame 5 should not also surface tier names ("Start free, then Pro"). The frames work together: frame 3 owns the tier structure, frame 5 owns the trial framing or the value echo, and the two don't overlap.
How does RevenueCat's 2026 paywall data shape the screenshot decision?
RevenueCat's 2026 paywall redesign case studies all improved conversion by going from MORE tiers visible to FEWER [4]. A driver-license-prep app gained 17% ARPU by reducing visible paywall tiers from three to two. A party-game app gained 31% install-to-trial and 64% revenue from the same simplification. A food app gained 72% install-to-trial by removing the multi-tier breakdown entirely. The pattern is consistent enough to shape the screenshot decision: if you ship a tier comparison frame, ship 2 tiers, not 3.
The data is from in-app paywall screens, not App Store screenshots. But the underlying psychology transfers. The driver-license-prep app moved its weekly option to a "View All Plans" link and led with annual and monthly on the primary screen [4]. The party-game app removed monthly entirely from the main view, leading with weekly and annual. The food app collapsed three pricing options into a single trial toggle. In every case, fewer visible tiers beat more visible tiers on install-to-trial conversion.
Translated to App Store screenshots:
- Two-tier frame beats three-tier frame. A "Free vs Pro" matrix outconverts a "Free vs Pro vs Premium" matrix by the same logic that drove the paywall redesigns. The third tier doesn't add information at the screenshot-reading speed.
- Hierarchy collapse beats hierarchy preservation. If your product has Free / Plus / Pro / Enterprise tiers, the screenshot should compress to Free vs Pro (where "Pro" represents "everything paid"). Tier ladders are paywall details; screenshot frames are decisions about whether to install.
- Capability count over tier count. Show 4-6 capabilities split across the two columns. Adding a third column halves the row width and the readability with it.
The Adapty 2026 anchoring framework adds one more layer: showing a high tier first ("Pro $19.99") makes the mid tier ("Plus $9.99") look like a bargain, and a decoy tier is designed to push users toward the plan you want them to choose [5]. That logic operates on the in-app paywall, where price is visible. On the App Store screenshot, where Apple 2.3.7 bans pricing [1], the anchoring lever doesn't apply. The comparison frame can't do anchoring work; it can only do capability work. That difference is why the screenshot tier comparison is a tighter problem than the paywall tier display.
The clean read from the RevenueCat data: don't replicate your in-app paywall in your screenshot. The paywall has more room, more interactivity, and pricing visibility the screenshot doesn't have. The screenshot's tier comparison is a simpler signal.
What anti-patterns kill tier comparison frame conversion?
A handful of patterns recur across subscription apps that ship a tier comparison frame and see no lift (or see negative lift). The common shape: the frame is doing paywall work instead of pre-install work.
Anti-pattern 1: pricing text. Any frame with "$9.99/mo", "Save 50%", "Best value", or a struck-through price violates Apple Review Guideline 2.3.7 [1]. Apple's screenshot review now flags pricing visible in screenshots and can reject the submission. The compliance failure is also a design failure: the user can't decide on price information they'll need to verify at the paywall anyway.
Anti-pattern 2: more than two tiers visible. A Free vs Pro vs Premium vs Team grid forces the user into a decision they haven't earned yet. RevenueCat's 2026 case study data shows two-tier paywalls outperform three-tier ones consistently [4]. The screenshot version of the same problem is worse because the screenshot has no interactivity to ease the decision burden.
Anti-pattern 3: feature lists longer than 6 rows. A 12-row capability matrix becomes unreadable at portrait screenshot size. Pick the 4-6 capabilities that genuinely differentiate the tiers. Everything else lives on the paywall or in the App Store description's first paragraph (the description hook patterns cover that surface).
Anti-pattern 4: tier names that don't match the product. If your product calls them "Free" and "Pro" inside the app, the screenshot should too. A screenshot labelled "Basic" and "Premium" when the in-app tier names are "Free" and "Pro" creates a recognition gap the paywall has to close. Match the screenshot labels to whatever the user will actually see after install.
Anti-pattern 5: pairing tier comparison with trial messaging in the same frame. A frame that shows Free vs Pro AND "Start free trial" overloads the slot. Pick one structural job per frame. The trial-messaging patterns belong in frame 5; the tier comparison belongs in frame 3.
Anti-pattern 6: using the comparison frame instead of an outcome frame. This is the structural mistake the rest of the framework guards against. Shipping a tier comparison in frame 1 or frame 5 cannibalizes the outcome work those frames have to do. The comparison frame is additive at frame 3, not a substitute for frames 1 or 5.
Most of these compound. A four-tier matrix with prices, "Best value" overlays, and a trial CTA in frame 5 is a screenshot set that's doing paywall work instead of pre-install work. Apple flags the pricing, the user can't read the four columns at portrait scale, and the trial messaging in frame 5 doesn't match the paywall's headline. The whole sequence leaks because frame 3 took on too much.
Ship the tier comparison frame your category supports
A tier comparison frame is a structural choice, not a default. Productivity, utility, and health-tracking apps earn the frame 3 slot because their conversion barrier is "which tier do I need?" Meditation, dating, and single-purpose games skip it because their conversion barrier is "does the app deliver?" RevenueCat's 2026 data on multi-tier paywalls suggests ship two tiers if you ship any, and Apple 2.3.7 forces capability-only framing without pricing [1][4].
The screenshot iteration moves faster once the slot decision is locked. If frame 3 is a tier comparison, design it as a two-column capability matrix and keep frame 1 fully outcome-focused. If frame 3 is a single-feature demonstration instead, ship that and let the paywall do the tier work after install.
Try AppScreenshotStudio today for free instead of redrafting the whole 5-frame sequence each time. The tier comparison decision is one chat message away, and the Custom Product Page A/B test framework gives you a way to test the comparison frame against a signature-feature alternative on real install traffic before committing.
References
- App Review Guidelines - Apple Developer— developer.apple.com
- Screenshot specifications - App Store Connect Help— developer.apple.com
- The State of Subscription Apps 2026— revenuecat.com
- How four paywall redesigns boosted conversions and revenue— revenuecat.com
- App Pricing Models: Top 5 Strategies in 2026— adapty.io