Build a product-page treatment the released app can support

Check the treatment’s supported surface

Apple’s product-page optimization documentation describes tests on eligible default product pages, not custom product pages or Apple Watch and iMessage product pages. Its treatment configuration starts from the original page and inherits unchanged assets. These controls were checked on 7 November 2026; verify the supported platform and current account before preparing production files.

Name the page and audience context the experiment is meant to change. If the acquisition campaign uses a custom product page, do not assume a default-page experiment will test that campaign destination. Record which visits can encounter the intended treatment and which routes remain outside this mechanism. The immediate question is whether the proposed experience exists on the selected surface, not whether enough visitors will produce a persuasive result.

Inventory changed and inherited assets

Build a manifest with one row for each relevant device size and localization. Mark the icon, screenshots and previews as changed, inherited or not applicable. An unchanged item is still part of the treatment the customer sees. Review the resulting combination, especially when a new screenshot headline makes a claim that the inherited preview does not demonstrate.

Apple documents that treatment icons must already be included in the current App Store binary with appropriate alternate-icon support. Ask engineering to identify the released build containing the proposed icon, rather than accepting a design-file export as evidence. If the icon is missing, narrow the experiment to supported assets or schedule the necessary product work. Do not label an icon treatment ready while its only implementation exists in a development build.

Separate asset readiness from a future release

For each proposed change, record whether the required metadata is approved and whether its binary dependency is already public. The current treatment guidance allows some metadata submissions independently of a new app version, but that does not remove the alternate-icon dependency. Keep the approval state and the build state in separate columns so one cannot conceal the other.

Review upcoming app releases with the experiment owner. Apple warns that a version release can affect a running test when it changes the assets or metadata under test. Write a decision for that collision before it happens: avoid the overlapping change, end the test under its agreed rules, or document why the resulting evidence cannot answer the original question. Never silently combine observations from materially different treatments under one convenient label.

Rehearse what installing the treatment means

Apple explains that a tested icon can appear during download and on the user’s device. The treatment is therefore more than a temporary decorative image on a store page. Ask the product owner to approve the icon’s recognizability in that continuing context, including how support staff will identify the app when a customer describes a different icon.

Record the final treatment composition and the released build before launch. A reviewer should be able to reconstruct each supported combination without reopening a designer’s working file. Keep the experimental success rule separate from this operational acceptance: a valid treatment may still perform poorly, and a promising mockup may still be unservable. The handoff is complete when the test operator has an accurate manifest, resolved dependencies and an explicit response to a release that changes the object being tested.

Make the reasoning concrete.

A fictional budgeting app proposes a new icon and a reordered screenshot sequence. The screenshots are already approved, but the proposed icon exists only in the next development build, while the live binary contains the old alternatives.

The team chooses the screenshot-only question and records inherited assets by device size. It does not describe the result as evidence about the unavailable icon.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Surface

   Is this the supported default page rather than a custom-page campaign?

2. Composition

   Which assets are changed and which are inherited?

3. Binary

   Which public build contains every proposed alternate icon?

4. Collision

   Could a scheduled release change the tested assets or metadata?

5. Continuation

   What treatment identity persists during download or on the device?

Watch for the wrong conclusion.

• Assuming a design export creates an available alternate icon.
• Ignoring inherited device-size assets.
• Calling a screenshot-only test evidence about an untested icon.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.

• Apple: Configure test treatments →Primary platform documentation · Supports: Supports inherited treatment assets, default-page scope, current-binary alternate-icon dependency and device icon behavior; manifest and release coordination are editorial.
• Apple: Overview of product page optimization →Primary platform documentation · Supports: Supports eligible page scope and warning that new app versions can affect running tests.