Product
Distribution and approvals
TestFlight, the App Store, Play, Firebase, S3 and OTA — each a named target that release.yaml refers to by name, with the account behind it resolved at run time.
Approval before bytes move
A distribution that needs sign-off does not upload and then wait. It waits and then uploads — because an uploaded TestFlight build is already visible to internal testers, and a system that guards the door after opening it is performing a control rather than applying one.
N distinct approvers, keyed on who
An approval policy asking for two approvers means two people. The decisions table is keyed on the request and the user, not counted — so the same person clicking twice is one approval, which is the only reading of “two approvers” that means anything.
Rollouts, and honest copy about them
Staged rollout on Play, phased release on the App Store, halt and resume on both. The console says plainly that iOS has no true rollback: halting a phased release stops it advancing and does not un-ship what already went out. A tool that implies otherwise is setting somebody up for a very bad afternoon.
Audiences that stay in step
One Conductor group maps to App Store Connect beta groups, Play testing tracks and Firebase groups at once, with drift detection when somebody adds a tester on the provider side. Which happens constantly, and is not a problem until nobody can say who is on the list.
What this part refuses to do
Each of these could be built, and each would make the product worse.
- Letting a caller supply the idempotency key
- A distribution’s key is derived from the artifact digest, the target and the track. A supplied key is a caller bug waiting to double-ship a build, and the derivation removes the possibility rather than documenting it.
- Running distribution on a build machine
- Every distribute step runs on the control plane. Putting standing store credentials on a Mac to make a REST call the control plane can make directly would be spending a real risk on nothing.