Product Page Optimization through the API (apple ppo) and an optional 6.3" iPhone size key
apple ppo status | create --variant b[,c] | upload --variant b | start | stop: v2 experiments (platform IOS, traffic proportion), one treatment per shots variant (max 3), a treatment localization per App Store locale, and the variant renders synced into the treatment screenshot sets (shared MD5-idempotent set sync with apple screenshots, which no longer creates sets on --dry). start / stop ask first and are not MCP tools; MCP: apple_ppo_status, apple_ppo_create, apple_ppo_upload. Play experiments stay console-only (documented). apple.iphoneMedium (off by default): iphone-medium size key, 1206 x 2622 (1179 x 2556 accepted), uploaded as APP_IPHONE_61; rendered, checked, required and uploaded only when enabled. Apple's scaling rule documented in the config and the store-screenshots skill.
This commit is contained in:
parent
20db1345e4
commit
d3cc7e43d4
12 changed files with 356 additions and 28 deletions
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: store-screenshots
|
||||
description: Produce store screenshots and the Play feature graphic for a mobile game in every required size and many languages - capture raw frames from the running game (web build via playwright, iOS Simulator via simctl, Android emulator or device via adb, or a folder of frames from any engine), write per-language marketing copy (incl. RTL Arabic and CJK fonts), render captioned scenes with device frames, review them in a local gallery, A/B variants for store listing experiments / Product Page Optimization, JPEG copies for Play, and upload to both stores. Use when the user needs App Store / Google Play screenshots, preview images, a feature graphic, localized screenshot captions, or screenshot sizes.
|
||||
description: Produce store screenshots and the Play feature graphic for a mobile game in every required size and many languages - capture raw frames from the running game (web build via playwright, iOS Simulator via simctl, Android emulator or device via adb, or a folder of frames from any engine), write per-language marketing copy (incl. RTL Arabic and CJK fonts), render captioned scenes with device frames, review them in a local gallery, A/B variants for Play store listing experiments and App Store Product Page Optimization tests (created and filled through the API), JPEG copies for Play, and upload to both stores. Use when the user needs App Store / Google Play screenshots, preview images, a feature graphic, localized screenshot captions, or screenshot sizes.
|
||||
---
|
||||
|
||||
# Store screenshots
|
||||
|
|
@ -27,8 +27,10 @@ Sources (re-check before a release; Apple renames display classes often):
|
|||
As of October 2026 the page marks "iPhone with Dynamic Island (medium display)" (1206 x 2622 / 1179 x 2556) as the
|
||||
required iPhone class, and says a class without its own screenshots gets scaled ones from the next class: medium
|
||||
from Face ID large (6.5"), 6.5" from Dynamic Island large (6.9"). So the 6.9" (+ 6.5") set still covers every
|
||||
iPhone, and storebound keeps 6.9" as the default. If App Store Connect ever refuses to submit without the medium
|
||||
set, render a 1206 x 2622 copy by hand (and open an issue so it becomes a size key).
|
||||
iPhone, and storebound keeps 6.9" as the default. For pixel-exact art on 6.3" phones (or if App Store Connect ever
|
||||
refuses to submit without the medium set), set `apple.iphoneMedium: true`: the `iphone-medium` size key (1206 x 2622,
|
||||
uploaded as `APP_IPHONE_61`, a mapping inferred from the enum, not verified) is then rendered, checked and uploaded
|
||||
like the others. It stays off by default.
|
||||
- ASC API `ScreenshotDisplayType`: https://developer.apple.com/documentation/appstoreconnectapi/screenshotdisplaytype
|
||||
(there is no "13 inch" value: the 13" iPad set is `APP_IPAD_PRO_3GEN_129`).
|
||||
- Play graphics: https://support.google.com/googleplay/android-developer/answer/9866151 (screenshots 320-3840 px, at
|
||||
|
|
@ -104,9 +106,19 @@ images there), so only do that after a test has a winner. What the stores offer,
|
|||
treatments against the original, one test at a time, up to 90 days; icon, screenshots and app previews, localized
|
||||
per treatment; new metadata goes through App Review; alternate icons must ship in the binary; shown on iOS / iPadOS
|
||||
15+. https://developer.apple.com/app-store/product-page-optimization/
|
||||
The App Store Connect API has the resources (`appStoreVersionExperiments` v2, treatments, treatment localizations
|
||||
with their own screenshot / preview sets), but storebound does not create or start experiments: set the test up in
|
||||
App Store Connect and upload the treatment screenshots there (the variant folder already has the right sizes).
|
||||
Through the API with storebound (`appStoreVersionExperiments` v2, treatments, treatment localizations and their
|
||||
screenshot sets):
|
||||
1. `storebound shots render --variant b` (and `shots check --variants`, `shots gallery`).
|
||||
2. `storebound apple ppo create --variant b --traffic 30 --dry`, then without `--dry`: one test with one treatment
|
||||
per variant (named after it, max 3 variants: `--variant b,c`) and a localization per App Store locale.
|
||||
3. `storebound apple ppo upload --variant b --dry`, then for real: the variant renders into the treatment's
|
||||
screenshot sets per locale (MD5-idempotent). MCP: `apple_ppo_create`, `apple_ppo_upload`, `apple_ppo_status`.
|
||||
4. **Owner**: `storebound apple ppo start` (asks first; treatments that are not approved yet go to App Review with
|
||||
the next version), later `storebound apple ppo stop` (final: a stopped test cannot be restarted; stopping through
|
||||
the API is `started: false`, not verified against a live test, so if it is refused stop it in App Store
|
||||
Connect). Neither is an MCP tool. Results per treatment are only in App Store Connect.
|
||||
The app must be live (Ready for Distribution); alternate icons and app preview treatments stay App Store Connect
|
||||
clicks.
|
||||
- Test one thing per experiment (usually the first screenshot or the order), give it real traffic, and do not read
|
||||
results early.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue