The Build‑Ready Launch Checklist: 15 Exact Files, Names & Metadata to Ship an App in One Sprint

Build‑ready isn’t handwaving: it means (A) technical binary ready with correct version/signing, (B) store assets in the exact sizes and codecs the stores expect, and (C) complete, store‑formatted metadata for each locale. Missing any of these halts release.

This section defines the acceptance criteria you will use at handoff so the engineering or release owner can proceed without chasing you for clarifications. Use the file and metadata names below exactly; they make automation and CI scripts predictable.

Create a /release-ready folder at the repo root. Inside it keep two platform subfolders: /ios and /android. The filenames and file types below are intentionally exact — scripts, CI, and release engineers will reference them directly.

Each file name uses kebab case and a single leading locale tag when applicable (en-US). Exact file extensions and simple naming conventions make it trivial to wire a GitHub Action, Fastlane lane, or a release checklist in Monday/Notion.

App Store previews are strict: supply device‑matched MP4s 15–30 seconds, H.264 or HEVC, 30fps, stereo audio track (even if silent), and exact pixel dimensions matching the screenshot size for that device. If you provide only one set, Apple may scale and reject for mismatched codecs — so prepare separate preview files per device family when possible.

Google Play is more permissive for promo videos, but use a 16:9 MP4 (H.264), keep the file under recommended size (~100MB), and provide a cover image (feature graphic) sized per Play Console guidance. Exporting with these presets minimizes iterations and upload failures.

Store metadata belongs in plain text or Markdown files inside localized subfolders. Use these exact filenames so your release manager or CI script can assemble the store payload without ad hoc parsing.

Keep one file per metadata field to make review and translation straightforward. For Apple you need title, subtitle, keywords, promotional text (optional), full description and release notes. For Play you need short description, full description, and any localized graphic alt texts.

Use this minimal sequence to avoid blocking: 1) Product exports assets and metadata into /release-ready and tags the repo; 2) Engineering uploads signed binaries and points the release manager to the repo; 3) Release manager uploads assets to App Store Connect/Play Console and fills in localized metadata by copying the text files; 4) QA verifies store preview and submits for review.

Do not interleave asset tweaks with binary signing. Treat the binary and asset/metadata bundle as atomic: if metadata or assets change after signing, create a new build. This discipline prevents repeated review cycles and saves days.