Apple Custom Product Pages: a designer's guide (2026)

Custom Product Pages are the App Store feature that turns one listing into many. Instead of sending every visitor to the same screenshots, you build alternate versions of your product page, each aimed at a different audience or campaign, and point traffic at whichever one fits. For a designer that isn't a small feature request. It's a decision about how your whole creative system is built.

What a Custom Product Page actually is

Inside App Store Connect you can create up to 70 Custom Product Pages per app. Each one is a full alternate version of your product page with its own screenshots, app previews and promotional text, and each gets its own unique URL. You hand that URL to a specific ad campaign or audience, and everyone who arrives through it sees that version instead of the default. Your main product page, the one that ranks in search and catches organic traffic, stays exactly as it is.

The point of the feature is tailoring, not testing. If you run a fitness app, you might build one page whose screenshots lead on running and another that leads on strength training, then send each to the ad set that matches. The person coming from a running ad lands on a page that looks like it was made for them, because it was.

This is not A/B testing

It's worth being precise here, because the two features get confused constantly. Custom Product Pages tailor the page to an audience you already know. They don't measure which version converts better. The feature that does that is Product Page Optimization (PPO), a separate tool that tests up to three treatments against your default page and reports conversion. Use CPP to match a message to an audience; use PPO to find out which creative wins. The two work together, and the screenshot design guide covers the testing side in detail.

What this means for the way you design

Seventy possible pages sounds like seventy times the work, and if you design each one from scratch it will be. The teams that use CPP well don't draw seventy independent sets. They build a system once and assemble variants out of it.

Design a modular set, not a finished one

Treat a screenshot set as parts rather than a single artwork: a background layer, a device frame, a headline block, a feature caption. When those are separated in your source file, producing a running-focused variant is a matter of swapping the headline and the captured screen, not rebuilding the slide. The goal is that a new CPP costs you an hour, not a day. If a variant means starting over, the system is wrong.

The first slides carry the whole idea

Each CPP still obeys the same rule every App Store set does: a browsing user sees roughly the first one or two screenshots before scrolling, and many never scroll. So the thing that makes a variant specific, the running message or the strength message, has to live in slides one and two. A variant that only differs at slide five isn't really a variant, it's the default page wearing a different URL. Front-load the audience-specific claim and let the shared slides carry the rest.

Localization multiplies everything

A CPP is localizable, which is the quiet cost. One page in eight languages is eight sets of text baked into images. Ten CPPs in eight languages is eighty. This is the strongest possible argument for keeping text in editable layers and out of flattened artwork, and for a naming scheme that encodes campaign, market and slide so you can find any of those eighty assets later. If you're still unsure of the exact canvas each of those needs, the screenshot sizes reference has the current numbers.

Keep a source of truth

The failure mode with CPP is drift. A page goes up for a seasonal campaign and never comes down, a market gets a variant nobody remembers commissioning, and six months later nobody can say which of the live pages is current. Keep one document that lists every CPP, its audience, its URL and the source file it came from. Without it, seventy pages becomes seventy things to audit by hand.

Learn from what competitors ship

You can't see a rival's CPPs directly, they sit behind campaign URLs, but you can study any set they've made public, including the default page and any campaign links you come across. Pull their sets at full resolution and lay them next to yours to see how they're splitting a message across variants, and how modular their own system looks.

Rivals also revise this creative more often than they revise the default page, because campaigns turn over. If you want to know when a competitor changes their store creative rather than checking by hand, screenshot change alerts watch a listing and tell you when the assets move.