App Preview | Blog

First-release checklist for App Store & Google Play

Wed, 24 Jun 2026 00:00:00 GMT

A first-release checklist for the App Store and Google Play is the difference between a smooth launch and a rejection email. A brand-new app has the strictest requirements, and they’re easy to miss when you’re focused on the build. This guide covers two things: the listing checklist (what every store needs), and the end-to-end deploy flow for each store — from account to “Available”.

What the checklist covers

Open Release checklist in the tool to verify, before you submit:

Screenshots — present for every required device size (iPhone 6.9”, iPad 13”, Android phone) with the correct dimensions and no alpha channel.
Metadata — name, subtitle/short description, keywords, and full description filled for every locale you ship.
Graphics — app icon (1024×1024 / 512×512) and Google Play feature graphic (1024×500).
Policy items — privacy, content rating, and category set.

Why a first release is different

For an app already on the stores, most fields carry over. A first release starts empty, so the checklist acts as a final gate — confirming each store has everything it needs before you hit submit. Two things also exist only on a first submission: setting up signing/distribution and getting through the stricter first-time review. The deploy steps below cover both.

Deploy to the App Store (iOS)

0. Prerequisites

Apple Developer Program membership (US$99/year) — enroll at developer.apple.com.
Xcode on a Mac (latest stable), signed in with your Apple ID under Settings → Accounts.
A unique Bundle ID (e.g. com.yourcompany.yourapp).

1. Create the app record in App Store Connect

Go to App Store Connect → My Apps → + → New App.
Pick the platform (iOS), name, primary language, Bundle ID, and a SKU (any internal id).
Set Pricing and Availability (free/paid, territories).

2. Sign and upload the build

In Xcode, set the Version (e.g. 1.0.0) and Build number.
Enable Automatically manage signing (Xcode creates the distribution certificate + provisioning profile), or manage them manually in Certificates, Identifiers & Profiles.
Select Any iOS Device (arm64) → Product → Archive.
In the Organizer, choose the archive → Distribute App → App Store Connect → Upload. (Alternatively, export the .ipa and upload with the Transporter app.)
Wait for build processing to finish in App Store Connect (a few minutes to an hour) before the build can be attached to a version.

3. Fill the version listing

On the app’s 1.0 Prepare for Submission page:

Screenshots — upload per device size (6.9” iPhone is required; iPad 13” if you support iPad). Prep them in the Playground.
Promotional text, description, keywords, support URL, marketing URL.
App icon is taken from the uploaded build (1024×1024, no alpha).
App Privacy — complete the data-collection questionnaire (required).
Age Rating questionnaire, Category, and Pricing.
Select the processed Build from step 2.

4. (Optional) TestFlight beta

Add internal/external testers under TestFlight to validate the exact build before public review. External testers require a quick beta review.

5. Submit for review → release

Choose how to release: Automatically, Manually, or Phased release (gradual rollout to existing users — for first release it controls the ramp).
Click Add for Review → Submit.
First-time reviews are stricter and can take from a few hours to a couple of days. Watch for Metadata Rejected vs Binary Rejected — the former you fix in the listing, the latter needs a new build.
On approval, the app goes Pending Developer Release (manual) or live automatically.

Deploy to Google Play (Android)

0. Prerequisites

Google Play Developer account (one-time US$25) — register at the Play Console.
Android Studio to build a signed Android App Bundle (.aab) — Play requires AAB, not APK, for new apps.
A privacy policy URL (required for essentially every app now).

1. Create the app in the Play Console

All apps → Create app → set the app name, default language, App or Game, Free or Paid, and accept the declarations.

2. Set up signing (Play App Signing)

Build a signed release AAB: Android Studio → Build → Generate Signed Bundle / APK → Android App Bundle, using your upload keystore (keep it safe — losing it means a recovery process).
Play App Signing is on by default: you sign with the upload key, Google re-signs with the app signing key it manages. This is what end users get.

3. Complete the store listing & policy declarations

Under Grow → Store presence → Main store listing and the Policy / Dashboard tasks:

Short description (≤80 chars) and full description (≤4000).
Screenshots (min 2 per form factor), app icon (512×512), and the feature graphic (1024×500) — prep these in the Playground.
Content rating questionnaire (IARC).
Target audience & content, Data safety form, Ads declaration, App access (login details if anything is gated), and Privacy policy URL.
Category and contact details.

4. Create a release on a track

Releases roll out through tracks — promote upward as confidence grows:

Internal testing → Closed testing → Open testing → Production.

Release → (track) → Create new release.
Upload the AAB, set the release name and release notes.
New personal-developer accounts may need a period of closed testing with N testers before Production is unlocked — check the console’s requirements.

5. Roll out & review

Review release → Start rollout to Production.
Use staged rollout (e.g. 10% → 50% → 100%) to limit blast radius.
First-app review typically takes from a few hours up to ~7 days. Once approved and rolled out, the listing goes live (propagation can take a few hours).

Prep your listing assets first

Both stores reject on the same avoidable things: wrong screenshot sizes, an icon with an alpha channel, a description that overflows, or a missing localized field. Build your New version in the Playground, run the first-release checklist, and fix anything flagged. Pair it with the store SEO audit so your launch listing is both complete and discoverable.

To pull credentials and live data for Sync / Test keys, see Get your API keys.

Load store screenshots & metadata via App Store & Play API

Wed, 24 Jun 2026 00:00:00 GMT

Loading store screenshots and metadata by hand is slow and error-prone. The store-preview tool pulls them straight from App Store Connect and Google Play using your API keys, so the Current variant always mirrors what is live.

What gets loaded

One Sync click reads, per store:

App Store Connect — iPhone and iPad screenshots plus the localized name, subtitle, keywords, promotional text, description, and “what’s new”.
Google Play — phone screenshots plus the title, short description, and full description for every locale.

Screenshots are downloaded into assets/current/ and the text is written to listing-current.json, so the Current variant reflects the live listing exactly.

How the API access works

The tool authenticates the same way the official tooling does:

App Store Connect uses a JWT signed with your .p8 API key (key id + issuer id).
Google Play uses a service-account JSON with the Android Publisher scope.

You only set these once. See the environment variables reference for every key, and Get your store API keys for step-by-step instructions on creating them.

Try it

Open the Playground, add your keys via Import → Env, click 🔌 Test keys to confirm access, then ⟳ Sync. Within seconds the Current variant shows your live App Store and Google Play listing — ready to diff against your new version.

One site — landing, Playground, and docs

Wed, 24 Jun 2026 00:00:00 GMT

The store-preview project used to be three separate things: a landing page, the interactive tool, and the documentation. Now it’s one site, served by a single serve.py umbrella and started with ./run.sh:

/ — the landing page introduces the product.
/playground/ — the interactive tool: Sync live data, Review Diff, Test keys, Try template.
/docs/ — these docs, plus the blog and the interactive API reference.

Everything shares one origin, so the Playground’s /api/* calls just work, and links between the marketing page and the docs are plain root-absolute paths.

Start it, and run.sh prints every route so you know exactly where to click:

→ Site:        http://localhost:8092/
  Playground:  http://localhost:8092/playground/
  Docs:        http://localhost:8092/docs/
  Blog:        http://localhost:8092/docs/blog/
  API ref:     http://localhost:8092/docs/api/

See The integrated site for how the routing works and how to deploy it.

Preview a new App Store & Google Play version before upload

Wed, 24 Jun 2026 00:00:00 GMT

Previewing your new App Store and Google Play version before upload catches the mistakes that are expensive to fix once a build is in review: the wrong screenshot order, a missing localized subtitle, a description that overflows.

New vs Current, side by side

The tool keeps two variants:

New — the version you’re about to upload. Fill it with Try template, Load images, or drag & drop, then edit the text on the page.
Current — what’s live now, pulled from the stores via Sync.

Switch between them to see your changes in a realistic App Store and Google Play layout — including the iPhone, iPad, and Android phone galleries, and every localized field.

Review the diff before you ship

Review Diff compares Current → New in one dialog:

Text & metadata — per-locale field changes (name, subtitle, description…).
Screenshots — slot-by-slot visual comparison, with a fullscreen lightbox.

Anything added, removed, or changed is flagged, so nothing slips through.

Try it

Open the Playground, build your New version, and hit Review Diff. For the full walkthrough see Usage and The integrated site.

Preview your store listing before you ship

Wed, 24 Jun 2026 00:00:00 GMT

Shipping a mobile update means juggling two pictures of your store listing: what’s live now, and what you’re about to upload. It’s easy to upload the wrong screenshot order, forget a localized description, or push a key that turns out to be missing a permission.

The store-preview tool puts both pictures side by side, locally, before anything leaves your machine:

New is what you’re about to submit — fill it from a template, from Load images, or drag & drop.
Current is what’s live — pulled straight from App Store Connect and Google Play with one Sync click.
Review Diff shows exactly what changed, text and screenshots, per locale.

And because credentials are the usual pain point, there’s a Test keys button that verifies your App Store Connect key and Play service account against the live APIs before you save them.

Start with the setup guide, then wire up your environment variables.

Store SEO audit — ASO checks for mobile app listings

Wed, 24 Jun 2026 00:00:00 GMT

A store SEO audit (App Store Optimization, or ASO) decides how easily users find your app. Two listings with the same screenshots can rank very differently based on how the title, subtitle, and keywords are written.

What the audit checks

Toggle ASO checks in the tool to scan your listing for both stores:

Length limits — App Store name (30) / subtitle (30) / keywords (100); Google Play title (30) / short description (80) — flagged when empty or over.
Keyword coverage — primary terms present in the highest-impact fields.
Per-locale — every locale audited separately, so a translated listing doesn’t quietly lose its keywords.

ASO tips it surfaces

Put your strongest keyword near the start of the title.
Don’t repeat the app name in the keyword field — it’s wasted space.
Use the subtitle / short description for a second keyword theme.
Keep each locale genuinely localized, not a copy of English.

Try it

Open the Playground, turn on ASO checks, and tune each field until the warnings clear. Combine it with the first-release checklist for a listing that’s complete and discoverable.