Shipshot guide
A release checklist for app-store screenshot metadata
A large share of listing problems are not design problems. They come from a screenshot that promises something the submitted build does not do, or shows material you cannot publish. These are checkable before you upload, and fixing them afterwards is far more disruptive than catching them now.
Match every visible claim to the submitted build
Read each caption while looking only at the build you are actually shipping. A feature that is finished on your branch, a plan that launches next month, or a screen behind a flag that is still off all count as claims the build cannot support. This is the single most common source of avoidable listing trouble.
- Install the exact build being submitted and follow each caption's claim through the app.
- Remove or reword any claim you cannot reach in that build.
- Check feature flags and staged rollouts, not just the main code path.
Show the app in use, not just its front door
A set built from splash screens, login pages, and marketing panels does not demonstrate the product. Show real working states with realistic content. If a login screen is genuinely part of the story, pair it with frames that show what happens after, so the set proves the app does something.
- Replace splash and login frames with working product states.
- Confirm each frame shows a state a user can actually reach.
- Keep interface content plausible rather than empty or placeholder.
Remove material you do not have the right to publish
Screenshots regularly carry third-party logos, other companies' interfaces, licensed imagery, real people's names and messages, and content pulled from services you do not own. A store listing is public publication. Review each frame specifically for material you cannot publish, and replace it in the demo data rather than obscuring it.
- Audit every frame for third-party marks, licensed media, and real personal data.
- Replace it in the underlying demo account and recapture.
- Confirm any brand or platform reference you keep is one you are permitted to show.
Be explicit about purchases and requirements
If the app is paid, requires a subscription, needs an account, or needs specific hardware, the screenshots should not imply otherwise. A set showing only premium features on a free-tier listing sets up a complaint at best. State the requirement plainly somewhere in the set rather than leaving the visitor to discover it after installing.
- Identify features shown in the set that require payment, an account, or hardware.
- Make that requirement visible rather than implied.
- Check the same claims against your listing description for contradictions.
Review checklist
Questions to ask before handoff
Do these checks guarantee approval?
No. They cover the screenshot and metadata mistakes that are within your control. Review the platform's current guidelines and the rest of the submission separately.
Can I show a feature that ships next week?
Not in the set for this build. Update the screenshots when the build containing the feature is the one people can install.
What if my app genuinely needs a login to show anything?
Show the post-login product states as the main evidence, and make the account requirement clear rather than hiding it behind an attractive first frame.
