App Store listing checklist
The App Store listing should match the app reviewers will test.
Metadata and screenshots are not just marketing assets. They help reviewers and users understand what the app does, what access it needs, and whether the submitted build matches the public claims.
App Store metadata preparation should happen before the final submission sprint. If the app name, description, screenshots, privacy policy, category, support URL, and reviewer notes are assembled at the last minute, the listing often drifts away from the actual product.
Official source note: Apple provides App Store Connect help for uploading screenshots and app previews, plus screenshot specifications for accepted formats and device classes: Upload app previews and screenshots.
Listing workflow
Quick answer
Prepare App Store metadata as a product truth checklist, not just launch copy.
The checklist includes app name, subtitle, description, keywords, categories, age rating, support URL, privacy policy URL, marketing URL, copyright, contact details, screenshots, app previews, reviewer notes, demo access, and claim review.
Quick answer: metadata and screenshot checklist
Listing preparation checklist
- App name and subtitle approved by the owner.
- Description explains real features without unsupported claims.
- Keywords reflect user intent without stuffing.
- Category and age rating reviewed.
- Support URL and privacy policy URL are live.
- Screenshots show actual product screens and important workflows.
- App previews are optional but should match the submitted build if used.
- Reviewer notes explain login, paid features, hardware, location, or restricted access.
- Metadata source files are saved for future updates.
Metadata that needs owner approval
Marketing teams may write the copy, but the product owner should approve it. App Store metadata can create review and trust problems when it promises workflows that are incomplete, uses claims the business cannot support, or hides restrictions that reviewers will encounter.
Metadata worksheet
| Field | What to check | Owner |
|---|---|---|
| App name | Brand, spelling, legal naming concerns | Founder or product owner |
| Subtitle | Clear one-line value without hype | Product and marketing |
| Description | Accurate features and limitations | Product owner |
| Keywords | Relevant search phrases, not repetition | Marketing |
| Support URL | Working support route | Operations |
| Privacy policy | Accurate and live | Owner and legal/privacy reviewer |
| Category | Best-fit category | Product owner |
Screenshots and app previews
Screenshots should help users and reviewers understand the app. Use real app screens. If you add framing, captions, or design treatment, do not misrepresent what the app can do. Avoid showing private customer data, real phone numbers, personal emails, live addresses, or sensitive business records in screenshots.
Show real functionality
Screenshots should reflect the submitted build, not a future roadmap or unimplemented design mockup.
Use dummy data
Replace personal names, emails, phone numbers, addresses, and financial data with approved dummy content.
Explain the core job
The screenshot set should cover the app's main value: onboarding, dashboard, task completion, outcome, and support path.
Check thumbnail readability
App Store screenshots are viewed quickly. Large UI states and clean hierarchy work better than tiny dense interfaces.
Review-safe claims
Claims should be specific and defensible. Avoid saying the app is the best, safest, official, certified, guaranteed, or compliant unless the business can support that statement. If the app handles regulated workflows, payments, healthcare, finance, education, children, or location, get owner review before submission.
Screenshots show unavailable features
Reviewers can reject or question metadata when listing assets do not match the build they test.
Privacy policy is generic
A generic policy that does not match the app, SDKs, account flows, or deletion path weakens trust and review readiness.
Support URL is not functional
App Review and users need a real support route. A dead page or placeholder creates avoidable friction.
No source file handover
Future updates become slower when screenshots, copy, and metadata decisions are not stored in an editable format.
FAQ
How many App Store screenshots are required?
Apple screenshot specifications define the accepted formats and device requirements. Treat one screenshot as a minimum and plan enough screenshots to explain the real app flows clearly.
Should App Store screenshots be real app screens?
Yes. Screenshots should represent the actual app and should not show features, claims, or flows that the submitted build does not support.
Who should approve metadata before submission?
The product owner should approve app name, subtitle, description, keywords, screenshots, support links, privacy links, claims, and reviewer notes before the build is submitted.
