# Lesson 24: App Store listing QA: approve and release metadata

Assemble a coordinated publication package and verify what actually becomes visible.

Prerequisite: Approved metadata, creative files and any custom-page specifications.

Teaching examples are fictional unless explicitly identified as platform definitions.

## Foundations

### Check the complete package

Review text, imagery, locale, device group, offer conditions and product version together. Verify file requirements against current specifications and inspect the rendered assets at useful viewing sizes. A file can have correct dimensions yet show an obsolete screen or unreadable text. Technical validation and editorial validation are separate checks, both needed before approval.

### Make publication a controlled handover

Assign who submits, who approves and who verifies the live result. Record any version or review dependencies in the console rather than assuming every field changes immediately. Preserve the previous approved assets for recovery. Avoid mixing an experiment treatment into the default listing unintentionally; the publication checklist should state exactly which surface each asset belongs to.

### Verify the result, not only the submission

A submitted draft is not the same as a visible listing. Once the relevant review and publication steps finish, inspect the intended storefront and locale, record what is visible and update the change log. Check that the public promise matches the app release. If something is wrong, use the agreed correction path and preserve the incident details for later analysis.

## Apply the method

### Create an asset-level release manifest

List every field and image by locale, device family, version and approval status. Attach the exact files to be uploaded, not a folder containing several ambiguous finals. Check dimensions and formats against current Apple specifications for the supported devices. A technical pass does not verify factual content, so review the depicted UI and claims separately. Include the previous approved assets and strings so the publisher can identify unintended changes and prepare a recovery path if the release needs correction.

### Separate console acceptance from editorial approval

A file can upload successfully while showing the wrong language or an outdated offer. Conversely, a well-reviewed design may fail a technical requirement. Use separate checks for content, language, asset format, console entry and product consistency. Have the reviewer inspect the actual entered fields and asset order before submission when access permits. Record any console errors verbatim with the affected asset ID. Do not repeatedly alter unrelated fields to make an unexplained error disappear; identify the specific requirement first.

### Verify what users can actually see

After approval and publication, inspect the target storefront, locale and device context. Compare the visible listing with the approved manifest, including screenshot order and fallback language. Record the observed-live time and any uncertainty about propagation. Check relevant links and the promised product path. If a mismatch is found, classify its severity and correct it through the authorized release process. Preserve the change log so subsequent performance analysis uses actual visibility rather than the earlier design or submission date.

## Procedure

1. Run separate technical, language, product-accuracy and message-consistency checks.
2. Confirm the publisher, approver, release dependencies and recovery assets.
3. Submit the approved package through the appropriate console workflow.
4. Verify the live store context and log actual publication rather than only submission time.

## Worked example

Trail Notes submits revised Australian screenshots while a product release is awaiting approval. The checklist records that dependency. After publication, a reviewer notices that the second image still shows an old export button. The team logs the discrepancy, corrects the asset and avoids attributing the entire week’s performance to a perfectly executed new sequence. The verification step prevents an inaccurate experiment narrative.

| QA gate | Evidence | Owner |
| --- | --- | --- |
| Content | Claims match current app | Product reviewer |
| Language | Final text and artwork reviewed | Locale reviewer |
| Technical | Files satisfy current specifications | Production owner |
| Live verification | Storefront matches approved manifest | Publisher |

These gates answer different questions and should not be collapsed into a single “approved” checkbox. A release can pass language review while still containing the wrong device export. The manifest links the decisions together and gives the publisher an unambiguous pack. If the visible listing differs from the approved pack, resolve that mismatch before presenting a performance chart as evidence about the intended treatment.

## Your ASO assignment

1. Create a release checklist with named reviewers and surface-specific assets.
2. Perform a dry run using your draft package.
3. Write a correction plan for the wrong locale or an outdated screenshot.

The correct English screenshots appear in the wrong order after publication. Explain why a successful upload is insufficient, how to document the mismatch and which date belongs in the later experiment timeline.

## Handover

### Manifest

Name every final field and file with locale, device, version and approval status.

### QA record

Separate factual, language, technical and console checks, including unresolved errors.

### Submission log

Record submitter, date, status changes and the exact submitted version.

### Live evidence

Attach dated storefront observations and note any propagation uncertainty.

### Recovery plan

Keep prior approved copy, correction responsibility and criteria for urgent action.

## Check your work

- The approved version is unambiguous.
- Live verification covers the intended locale and surface.
- Changes and discrepancies are traceable in the publication log.

## Common mistakes

- Calling a draft submitted to review a completed deployment.
- Assuming valid image dimensions prove content accuracy.

## Knowledge check

All files passed validation but the wrong language is live. Is the release complete?

No. Correct the publication context, verify the intended storefront and document the actual visible period. Technical file checks cannot establish that the right assets reached the right audience. Use the incident to improve the handover and measurement notes.

## Sources

- [Apple — Screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications/) — Current device-specific screenshot formats and dimensions.
- [Apple — Platform version information](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information/) — Field definitions and submission constraints, including keyword bytes.

Platform references reviewed 29 September 2026.
www.asoagency.com