Keep the release candidate still while evidence arrives
A mobile release review needs a fixed candidate. Changing the package while checks are underway makes every approval harder to trust.
A team has a candidate mobile package. One person is checking launch behaviour, another is reviewing the destination, and a third spots a small configuration change. The temptation is to rebuild immediately and keep the review moving. Now two packages exist, and it is no longer clear which one the passing checks describe.
We treat the candidate as a fixed object while evidence is gathered. That does not mean the code cannot change. It means a change creates a new candidate with a new identity, and the release record should say so. A moving package makes every approval conditional on a memory of which file was in front of the reviewer.
Freeze the object, not the investigation
A useful candidate record includes the artifact digest, app identity, version, build configuration, intended destination, and the source revision that produced it. Those fields let reviewers attach findings to one package. The investigation can continue: people can test, inspect, and challenge the candidate. What stays fixed is the object under review.
If a reviewer finds a flaw, the record should keep the finding against that candidate even after a replacement is built. Deleting the failed result because a newer package exists loses the reason for the rebuild. It also makes it easy to repeat the same mistake when an older artifact appears in a later handoff.
A candidate can be abandoned without being erased. Mark it superseded, name the replacement digest, and preserve which checks were completed before the change. A later operator should be able to answer a simple question: did this artifact fail, become irrelevant, or merely wait for evidence? Those are different states.
Decide which evidence can carry forward
Not every change invalidates every observation. A correction to release notes may leave a package smoke result relevant to the same binary, while it reopens store submission review. A changed package binary invalidates any check whose purpose was to inspect or run the old bytes. A changed destination may leave compilation proof intact while reopening audience and credential checks.
The rule is to attach evidence to what it actually tested. A launch smoke for digest A remains a true historical result for digest A. It is not a launch smoke for digest B because both carry the same visible version. Likewise, a provider receipt for an internal track cannot be reused as proof that a public track accepted the package.
A small evidence map helps. For each check, record the candidate identity, destination where relevant, time, result, and condition that would require a rerun. This is more useful than a single green release badge. It also makes the cost of a late change visible before somebody presses rebuild. Teams can then decide whether the fix is essential for this release or belongs in a later candidate. That decision should rest on product risk and evidence, not on how inconvenient a second round of checks feels. If the fix is needed, make the new candidate explicit.
Make replacement a deliberate handoff
When a new package is necessary, the release owner should state why the old candidate was replaced and what work must restart. The replacement inherits the plan, not the passing results by default. If a result can carry forward, name why its subject did not change. If that argument is unclear, run the check again against the new candidate.
This discipline matters near store submission. Upload, processing, review, and audience availability are separate provider states. A replacement package may have the same marketing version yet a different build number or digest. The release record needs to show exactly which artifact the provider received and which earlier evidence supports it.
The same rule protects against a subtle failure: a reviewer checks a local file, but the submission job picks a different file from a shared folder. Comparing digests at the handoff is cheaper than discovering the mismatch after a store response. If the bytes differ, stop and establish which candidate was intended.
Ubriot is built around evidence that travels with a mobile release. We want a candidate to stay identifiable while decisions arrive, even when a fix creates a successor. Fixes are welcome. Borrowed proof is not. Keep the artifact still enough that another operator can see which package passed, which package failed, and which package is being sent onward.