The Final Check Before the First Submission

Previous: Review Submission Takes More Than Upload

Near a first submission, it is tempting to combine familiar claims: payments were tested, ads were seen, a package was exported, and store materials were prepared. It can seem that only a summary remains.

The problem is which version each claim describes. Payment may have been tested yesterday, screenshots may show an older interface, the archive may have another build number, and review notes may describe a flow changed today. Each result can be true without proving anything about the candidate about to be submitted.

Kibble Street TD's final check therefore centers on one question: can the team prove that the app running on the device, the product described in the store, and the version reviewers will test are the same candidate? This article describes that acceptance method; it does not claim a submission has occurred.

Freeze the candidate before accepting it

A candidate is more precise than “the latest version.” Its identity includes a fixed feature scope, version and build number, signed archive, exported package, matching store materials, and evidence from this acceptance round. Together they define one submission boundary.

Fixes are still possible after freezing, but old evidence does not automatically apply to them. Changes to runtime logic or the package invalidate affected archive, installation, device-flow, payment, and ad evidence. Changes limited to screenshots or review notes still require the affected material checks and remote readback.

An earlier signed archive and package export had succeeded, including debug symbols, entitlements, and a privacy manifest. That established a working build pipeline at the time. Later code and material changes meant it could not impersonate the new candidate. Old results demonstrate prior capability, not this delivery.

One acceptance table should cover six layers

A checklist organized only by department can produce vague statements such as “engineering done” or “store done.” Six layers organized by risk are more useful. Each records an expected result, actual evidence, an owner, and a status.

First is scope: what the launch includes and excludes, and whether temporary test switches are disabled. Second is binary identity: version, build, signing, entitlements, privacy manifest, and debug symbols from the same archive. Third is device behavior: fresh installation, existing saves, restart recovery, and the core game path.

Fourth is monetization and consent: transactions recover without duplicate rewards, rewarded ads grant only after authorization, and ads start only when consent permits them. Fifth is the store contract: names, copy, screenshots, purchases, privacy answers, and review instructions describe the same behavior and are read back from the platform. Sixth is risk: blockers, explicitly accepted limitations, and questions that need post-launch observation.

These are six views of one candidate. Combining green results from different versions does not establish that all six passed together.

Verify identity throughout the artifact chain

At least four artifacts separate the project from the device: selected source, a signed archive, an exported package, and the installed app. Every transition adds variables, so checking only whether the final app opens is insufficient.

Lock scope and version at source selection. Check signing, entitlements, privacy, and debug symbols in the archive. After export, record the package fingerprint and inspect key files. After installation, read the actual installed version and complete the startup path. Failures can then be traced to source, archive configuration, export, or the device environment.

An archive proves archiving; export proves that a package was produced. Neither proves device behavior, platform processing, or review status. If runtime logic changes afterward, device results from the old package no longer belong to the new candidate.

Follow the path of a reviewer seeing the game for the first time

A developer's everyday device often retains saves, authentication, and previously granted permissions. It can bypass first-launch problems. Final acceptance should cover at least a fresh installation, an upgrade with an existing save, and a complete quit followed by relaunch.

The fresh path starts with consent and faction selection, reaches Home, completes a battle and settlement, tests purchases and rewarded ads in the shop, and checks privacy and terms in Settings. Existing saves must retain the correct stage, currency, items, and processed transactions without duplication. Relaunch must restore saves, recover unfinished transactions, and route to the correct screen.

Review notes should use the same sequence. Someone without internal knowledge must be able to follow it. If a step does not work on the candidate, correct the product or the instructions rather than relying on an explanation only the development team understands.

The success path is not enough

A purchase is especially risky when payment, fulfillment, or saving has happened and the next step is interrupted. The transaction pipeline accepts verified transactions, saves rewards, and then finishes. Repeated delivery must not grant again. Fulfillment and finish failures must retain their appropriate recovery paths. Automated checks can cover these state transitions, but the actual store environment still needs testing with this candidate.

Rewarded ads likewise cannot treat dismissal as an earned reward. The explicit reward event authorizes fulfillment. No fill, network failure, early closure, or callback errors must leave rewards ungranted. Initialization must also respect consent: an app without permission to request ads must not start the ad service early.

Automation repeats state-machine checks well. A human still needs to judge system prompts, payment panels, ad presentation, and return paths on a real device. Keep both kinds of evidence.

Known risks need an explicit decision

A final check assigns an actionable outcome to each issue instead of relabeling every problem as solved.

Blockers undermine candidate identity, core gameplay, payment recovery, privacy promises, or the review path. They require a fix, rebuild, and retest. Accepted risks are bounded limitations outside critical paths, with documented impact, a named accepting owner, and a follow-up date. Post-launch observations concern questions real data must answer, such as ad fill, conversion, device performance distribution, and where players leave.

AI can find contradictions, organize evidence, and point out gaps. It cannot accept risks for the project owner. Acceptance needs a decision-maker, rationale, and a date to revisit it; otherwise “known risk” is only another name for an omission.

The final decision is Go or No-Go

Submission requires all necessary conditions together: frozen scope, no blocking automated failures, matching archive/package/device identities, a passed device review path, payment/ad/recovery verification on this candidate, correct build and materials confirmed by platform readback, and explicit human authorization.

Any red requirement means No-Go. Fix its source and recreate affected evidence. Do not manually recolor the acceptance table. Go authorizes the specific act of submitting this candidate for review; it does not extend automatically to release or later versions.

What the human and AI each contribute

AI performs repeatable checks: compare version identities, inspect configuration and material references, validate image specifications, exercise purchase and ad state machines, associate each result with its candidate, and mark evidence invalid when inputs change.

The human handles real-device operation, experience judgments, privacy and commercial commitments, risk acceptance, and final authorization. AI can compress many checks into a clear decision table. Deciding whether the candidate is worth submitting remains a product responsibility.

If you want to start

Write down one candidate identity before copying a long generic release checklist. Make six rows: scope, binary, device, payments and ads, store contract, and risk. Use four columns: expected result, actual evidence, owner, and status. Remove old screenshots, old packages, and verbal assurances that cannot point to this candidate.

These first 18 articles reach the boundary of a first review-ready version. Further installments will follow events that actually happen—review feedback, real player data, or another development iteration—rather than assigning outcomes in advance.