Skip to content

Blog

App Store Connect release checklist

The things that actually hold up a submission, in the order you hit them. Written as a list you can run down before pressing Submit for Review rather than after the rejection email.

A row of smoked glass panels with a bright chrome rule beneath them

Most rejections are not about your code. They are metadata, screenshots, privacy answers and a missing demo account — all of which are avoidable in ten minutes if you check before submitting rather than after.

Run down this list.

Build

  1. The build you selected is the one you meant. Check the build number, not just the version.
  2. It has finished processing. A build still processing cannot be submitted.
  3. Version number is higher than the last released version.
  4. Export compliance answered. If your app uses HTTPS and nothing else, the standard exemption usually applies — but answer it deliberately rather than clicking through.

Screenshots

This is where most avoidable delays live.

  1. Exact pixel dimensions for every display class. App Store Connect compares integers, so 1280 × 2768 fails where 1284 × 2778 passes. If you hit this, the fix is here.
  2. Consistent within each class. All screenshots in one display class must share the same size.
  3. No alpha channel. Flatten transparency before upload.
  4. 6.9-inch iPhone present. Plus 13-inch iPad if your app supports iPad.
  5. Nothing fabricated inside a device screen — no invented ratings, download counts, streaks or reviews. Guideline 2.3.3 requires screenshots to reflect actual use.
  6. No other platform's device visible. An Android frame in an App Store listing is a rejection.
  7. No pricing in the images unless it is genuinely accurate everywhere, forever. It will not be.
  8. Screenshots reflect the build you are submitting, not the previous one.
A row of smoked glass panels with a bright chrome rule running beneath them
A quick verification pass: one row per display class means every file in that class matches.

A ten-second check over your export folder:

magick identify -format "%w x %h  %f\n" *.png | sort | uniq -c

One row per display class means you are clean. Two rows means one file is wrong, and it tells you which size is the odd one out.

App previews, if you use them

  1. Correct duration and dimensions for each display class.
  2. Captured from the app itself — not a promo edit with external footage.
  3. No device frames inside the video, and no hands or people holding the phone.
  4. Poster frame chosen deliberately; it is what people see before pressing play.

If you are unsure whether to bother, see app previews vs screenshots.

Metadata

  1. Name within 30 characters, subtitle within 30.
  2. Promotional text within 170 — remember this one can be updated without a new build, which makes it the right place for anything time-sensitive.
  3. Keywords within 100 characters, comma-separated, no spaces after commas, no words already in your name or subtitle, no competitor names.
  4. Description within 4000, and not stuffed with keywords — the description is not indexed the way people assume.
  5. Support URL resolves and is not a 404.
  6. Marketing URL, if given, also resolves.
  7. What's New written for this version specifically, not left as the previous one.

Review information

The single most common cause of a slow review:

  1. Demo account provided if anything is behind a login — with a working username and password, checked today, on the submitted build.
  2. Notes explaining anything non-obvious: hardware requirements, a feature that needs specific data, a region lock.
  3. Contact details for someone who will actually see the email.

Privacy and rating

  1. Privacy nutrition labels match what the app actually collects — including anything your SDKs collect on your behalf.
  2. Privacy policy URL resolves and covers what the labels declare.
  3. Age rating answered honestly, including user-generated content and unrestricted web access if applicable.
  4. Account deletion available in-app if your app supports account creation.

Pricing and availability

  1. Price tier and territories correct.
  2. In-app purchases submitted alongside the build if this is their first release — a common oversight, because they are a separate submission step.
  3. Release option chosen: manual, automatic, or scheduled.
  4. Phased release on or off deliberately.

Before you press Submit

Read your own listing on a phone, as a stranger would. Does the first screenshot say what the app does? Does the subtitle add something the name does not? Is the What's New text a sentence a human would write?

That last pass catches more real problems than any checklist, including this one. If the answer to the first question is no, the ASO screenshots guide is where to go next — and it is worth fixing before submission rather than after, because a metadata-only change still needs review.

Specs & fixes

App icon sizes, and what makes an icon work at 40 pixels

Every size iOS and Android actually need, why the store's 1024 is the least important one to design for, and the three things that separate an icon that survives a home screen from one that does not.

Read
Specs & fixes

Fix "The dimensions of one or more screenshots are wrong"

App Store Connect rejects a screenshot set on exact pixel counts, not on aspect ratio. Here is what it is actually checking, and how to find the one file that is four pixels off.

Read
Specs & fixes

Common App Store and Google Play rejections, and what they actually mean

Rejection messages are terse and rarely name the file. A translation guide for the metadata and screenshot rejections you are most likely to hit, with the specific fix for each.

Read