Review Submission Takes More Than Upload

Previous: Keeping Analytics and Platform Services Separate from Game Logic

An installable, runnable game is not automatically ready for review. Upload is a prominent button and feels like a finish line: choose a package, wait, and receive confirmation. In reality, it only transfers a particular build into the platform's processing queue.

Preparing Kibble Street TD's first submission revealed work spread across the binary, listing, review instructions, privacy declarations, purchases, and screenshots. An upload cannot turn stale content, placeholders, or missing associations into a complete release.

One version has two deliverables

The first is the app players install: version and build numbers, signing, entitlements, privacy files, third-party services, and runtime behavior. The second is the platform record: name, description, localized copy, screenshots, purchase information, privacy questionnaire, review instructions, and release mode.

Both must describe the same product. A game without an account system should not list a test account. If every paid product is consumable, its materials should not describe subscriptions or subscription restoration. If ads initialize after the consent flow permits them, the privacy description must reflect that behavior.

Review materials are an external contract for the version. Changes to product behavior require corresponding changes to that contract.

Upload is one state in the release process

The build flow separates mobile-project generation, archiving, package export, and optional upload. Archiving checks version, build number, display name, and debug symbols. A successful upload means waiting for platform processing before internal distribution becomes available.

At least six states need separate names and evidence: built, archived and exported, uploaded, processed, submitted for review, and released. Upload success does not prove processing success or complete screenshots, purchases, and privacy materials. Availability to internal testers does not establish entry into the review queue.

The workflow recorded here kept upload, purchase synchronization, review submission, and release as separate explicit actions, with automatic changes disabled by default. The point was to avoid one command changing several remote states before the materials had been checked.

Review notes should let a stranger test independently

Reviewers did not participate in development and should not have to guess where features live. The notes explain that the game has no in-app account and stores progress locally. Optional leaderboard authentication uses the reviewer's Apple ID. Paid products are consumables, without subscriptions or a Restore Subscription button. Unfinished transactions resume on launch. Ads start only after consent permits them, and the implementation does not request tracking authorization.

The notes also describe a path through first launch, faction selection, battle, the shop, purchases, rewarded ads, and Settings links for privacy and terms. This is a short test manual. A sentence that no longer matches the interface can turn a testable feature into an avoidable review question.

Privacy needs more than one file

The packaged privacy manifest passed format checks, and build configuration required its inclusion in the main app. A missing file stopped generation. It declared tracking disabled and described data categories such as product interaction, crashes, device identifiers, purchase history, and gameplay content, together with required reasons for relevant system APIs.

That covers only part of the problem. Four sources must agree: actual code and third-party behavior, the packaged manifest, the store privacy questionnaire, and the review instructions. Local inspection can check the first two. Current backend answers require remote readback; an old synchronization record cannot establish that they still match.

File counts do not establish completed localization

The publication materials contained 33 language files, with nonempty core fields and secure links. The directory structure looked broadly localized. Field-by-field comparison told a different story.

Alongside the English baseline, only 10 files had distinct descriptions and release notes. Another 22 non-English files reused English text. They were technically populated files, but that did not mean translation into 32 other languages was complete.

AI is useful for finding empty fields, duplicate copy, excessive length, and suspicious links, then producing a focused review list. Humans decide which launch languages are supported, where an English fallback is acceptable, and whether translations preserve gameplay and monetization meaning.

Screenshots need a traceable mapping

Store screenshots and purchase-review images can both start from gameplay, but serve different audiences. Store images explain the experience to players and occupy slots by device, language, and order. Purchase-review images show reviewers where a specific product is reached, what it sells, and how it fits the test path.

Start with the candidate build running in the intended environment. Classify each capture by purpose, then check dimensions, alpha channels, text, and visible content. Bind store images to devices and languages, and purchase images to specific products and review steps. After upload, read the platform record to confirm that the correct image reached the correct slot.

The mapping matters as much as the image. A changed screen, product, translation, or candidate requires the affected slots to be checked again. A file on disk proves an asset exists. A traceable candidate, image, slot, and remote result proves the screenshot work is complete.

Readiness requires a complete evidence chain

Review readiness means all materials form an evidence chain around one candidate. The first gate verifies binary identity: version, build, signing, entitlements, and privacy manifest. The second checks the store contract: descriptions, translations, screenshots, purchases, and review notes. The third performs local validation for length, references, formats, missing fields, and placeholders.

The fourth gate reads the platform back. The candidate must be processed, materials must belong to the intended version, images must occupy the correct slots, and purchases must be in the required review state. The fifth follows the review path on a device from a fresh install through gameplay, payment, consent, and legal links.

All five gates use one candidate identity and one material revision. A failure returns to its source for correction and verification. Old screenshots, manually skipped checks, and previous sync states cannot fill the gap. Only after the evidence is complete does the responsible human authorize review submission.

What the human and AI each contribute

AI can maintain the evidence table: compare product identifiers, measure repeated language copy, check image specifications, validate field lengths and references, and expose conflicts among the binary, listing, and instructions. It can run repeatable gates without confusing upload success with completed submission.

The human owns product promises: launch languages and regions, concise descriptions that retain meaning, accurate privacy answers, context reviewers need, and permission to change platform state.

If you want to start

Choose a candidate and freeze its scope. Record binary identity, store contract, local checks, platform readback, and the device review path. Give each an input, expected result, and actual evidence. Do not advance past an unpassed gate. Once all five are complete, review submission becomes a concrete, separately authorized action.