Check the release artifact after the build says yes
A green build creates a candidate. A responsible release connects the exact package, its identity, and every later check to the same artifact.
The build job finishes green. A mobile release candidate now exists, but the green result answers a narrow question: the build process completed. It does not prove that the file handed to a tester or store is the file the team intended to ship.
We treat the built artifact as a separate object that needs its own checks. The source revision, build configuration, signing identity, package identifier, version, and output digest should meet again in one release record. If they cannot be connected, a successful build can still lead to the wrong release.
Give the file an identity
A version label helps people talk about a release. It does not uniquely identify the file. Two builds can use the same visible version while containing different code or configuration. A filename can be copied, renamed, or replaced. Keep a cryptographic digest of the actual output and attach subsequent checks to that digest.
The build record should also say which source revision and configuration produced the file. That connection gives an operator a way to answer a practical question: which candidate did this smoke result, approval, or submission refer to? Without it, a passing check can drift away from the bytes that are eventually uploaded.
The digest is not a seal of quality. It is a stable reference. It lets the team notice when a later file differs from the one that passed inspection. A different digest requires renewed explanation, even if the human-readable version stayed the same.
Inspect what can be inspected
Before submission, check the package identifier, platform, version fields, and signing summary from the produced package. Compare them with the intended destination. A production build carrying a development identifier is not made safe by a green compile. A package signed with an unexpected identity needs investigation before anyone treats it as a release candidate.
Some checks require installation or a device. Record those separately. A static package inspection can verify metadata and signatures; it cannot prove that the app opens, reaches a key screen, or uses the expected production service. A device smoke can show observed behaviour; it does not prove every permission, network state, or store review condition.
We prefer each result to name its scope. Package inspection passed for digest A. Launch smoke passed on a named platform and OS version for digest A. Store submission accepted digest A for the intended track. Those statements can be checked and compared. Release ready, without the supporting objects, is a much weaker statement.
Do not let a rebuild borrow old proof
Suppose an operator fixes a configuration value after the first build. They rebuild under the same app version and upload the new file. The earlier smoke result may still be useful history, but it belongs to the earlier digest. It should not appear as a check on the new candidate.
The same rule applies when a package is downloaded from a build worker, copied through storage, and submitted later. Verify the digest at each handoff where the file might change. The check is cheap compared with discovering that a tester reviewed one binary while the store received another.
If the digest changes unexpectedly, stop and trace the path. It may be a legitimate rebuild, a packaging step that altered the file, or a mistaken selection. The point is not to assume wrongdoing. The point is to avoid explaining away a difference before knowing what changed.
Make the last handoff legible
A useful release handoff is short. It names the candidate digest, version, package identifier, signing check, smoke result, destination, and any unresolved caveat. It says who can proceed and which action would invalidate the proof. If a store accepts the upload, retain its reference and state without treating acceptance as proof that the release is already available to users.
Credentials deserve a careful boundary. A record can identify the configured signing or store credential reference and the outcome of its use. It should not copy secret material into a log or an article. Operators need provenance and accountability, not a credential dump.
Ubriot is built around the work between a successful build and a responsible release. We want the artifact to carry its evidence through that interval. A green build is a good start. The release decision is stronger when every later check names the exact file that passed it.
The next time a build turns green, ask one concrete question before the congratulations: can another operator identify the exact package, inspect its intended destination, and follow its proof through submission? If the answer is yes, the build result has become a release candidate. If the answer is unclear, keep the candidate in review until the chain is complete.