About
Why this exists
Mobile release tooling is either a hosted service that holds your signing keys, or a pile of shell scripts somebody wrote in 2019 and nobody understands. Neither is a good answer.
The hosted services are genuinely good at the part they are good at. They are also where your Apple distribution certificate lives, they charge by the minute for compute you increasingly supply yourself, and the day you want to move a project to a different developer account you discover that the account id is written into forty places.
The shell scripts are yours, which is the whole appeal, and they have no audit trail, no approval model, no credential scoping, and exactly one person who knows why the iOS job passes -allowProvisioningUpdates.
Conductor is the third option. One binary, your Postgres, your Macs, your keys — with the parts that are genuinely hard to get right built properly: credential scoping per job, fork pull requests that cannot touch a secret by construction, approvals checked before bytes move, and a hash-chained audit log.
What it is deliberately not
- A CI system
- It does not want to run your backend tests. It wants to take a merged pull request to a signed build in somebody’s hands, which is a narrower job with much harder edges.
- A Mac cloud
- You bring the machines. That is a constraint, and it is also why nothing here gets more profitable when your builds get slower.
- A replacement for fastlane
- If you have a Fastfile that works, adopt mode runs it unchanged. Typed steps are offered, not required — and a lane gets exactly the credentials its step declares, which is more than it had before.
- Finished
- It is built in the open against a written specification, and the build status document says what works, what does not, and what is missing. That list is longer than a marketing site usually admits.
Built by Mangozest Labs
Conductor started as internal tooling for about ten mobile projects across Flutter, React Native and native codebases, on a fleet of two MacBooks that are not interchangeable. Most of the design decisions on this site come directly from that: capability matching exists because an Intel Mac cannot run the same Xcode as an Apple-silicon one, and portability exists because moving a project between developer accounts turned out to be the thing nobody had planned for.