---
title: "App Store release QA checklist"
description: "A pre-submission checklist that covers naming, metadata, screenshot storytelling, locale consistency, and stakeholder review."
excerpt: "Use this checklist to catch the gaps that usually surface after screenshots, keywords, and translated copy leave draft status."
source_url: "https://storepilot.cc/guides/release-asset-qa-checklist"
mirror_url: "https://storepilot.cc/mirror/guides/release-asset-qa-checklist"
section: "Editorial guides for app-store growth teams"
locale: "en"
published_at: "2026-05-07"
updated_at: "2026-05-07"
reading_time: "6 min read"
tags:
  - "QA checklist"
  - "App Store"
  - "Google Play"
  - "localization"
---

## Direct answer

Use this checklist against the actual release candidate before pushing to App Store Connect or Google Play Console. Submission QA is not just a copy proofread. It is the final coherence check that confirms the current metadata, screenshots, localization, legal links, and approval state still describe the same product story.

## QA map

| QA area | What to check | Failure if missed |
| --- | --- | --- |
| Naming | Title and subtitle still match the current product promise | The listing opens with the wrong positioning |
| Keywords | No keyword set contradicts metadata or screenshot claims | Search intent and conversion message drift apart |
| Screenshots | Headlines are readable, specific, and aligned with the visual focus | The visual sequence stops proving the metadata promise |
| Localization | English and Chinese express the same strategy in different language | Locales start making different promises |
| Legal | Privacy, support, refund, and contact links resolve correctly | Submission readiness breaks on non-copy details |
| Review ownership | One owner can confirm the current approved package | The team cannot tell which assets are final |

## Recommended review order

### 1. Confirm the package name and positioning first

If the title and subtitle are already off, the rest of the QA pass is checking the wrong story.

### 2. Check keyword and metadata alignment

Make sure the keywords still support the same acquisition angle as the visible copy and screenshots.

### 3. Review screenshot readability and proof order

Every frame should still be readable, specific, and visually aligned with the message it is supposed to prove.

### 4. Validate localization parity

English and Chinese should express the same strategy, not two different interpretations of the product.

### 5. Verify legal and support surfaces

Broken privacy, support, refund, or contact links can block a release even when the creative assets look finished.

### 6. Confirm the approval owner and final package

Someone should be able to say which package is approved right now. If nobody can do that, QA is not done.

## Common release-week misses

### Teams QA fragments instead of the release candidate

Reviewing screenshots from chat and descriptions from another doc is not enough. QA only works when the team checks the actual package that will be submitted.

### Localization is treated as wording review only

If parity is checked only at the sentence level, the Chinese and English listings can drift into different strategies.

### Nobody owns the final approval state

When there is no clear approval owner, teams often discover at the last minute that they were reviewing different asset versions.

## Operating rule

Run QA against the current release candidate, not against scattered fragments. If one owner cannot confirm the latest approved package, submission QA is still incomplete.