Framework

Native iOS CI/CD you can self-host

xcodebuild archive and -exportArchive on your own Macs, with signing material scoped to the job that needs it and dSYMs kept for every build.

The pipeline, step by step

  • ios/bootstrapSPM resolve and pod install
  • ios/buildarchive and export, signed or not
  • ios/testXCTest and XCUITest on a simulator
  • distribute/testflightupload, after approval if the target asks for it

Every one of these is in the step library, with the credentials it can ask for and whether it may run on a fork’s pull request — generated from the file the server itself reads.

Xcode version is matched, never installed

A job that needs Xcode 16.4 goes to a machine that has it. Xcode is far too large to install on demand, so it is a declared runner capability — and a project that needs a version no machine carries is a job that waits visibly rather than a build that fails after a forty-minute download.

A pull request builds unsigned

Unsigned, and archiving skipped. That is a capacity decision — archiving is the expensive half — and a safety one at the same time: an unsigned build resolves no signing credential, which is exactly what lets a fork’s pull request run at all.

Adopt your Fastfile, or do not

If you have a Fastfile that works, adopt mode runs it unchanged — and Conductor reads it to find your lanes rather than executing it to ask. A lane declares the credential purposes it uses and gets exactly those, which is more than it had before.

What a build produces

IPA, dSYM archive, and the xcresult bundle from tests.

Symbol files are collected on every build rather than on the ones somebody remembers to configure. A crash report that arrives three weeks later resolving to a memory address is a crash report nobody can act on, and the difference is a build-time decision that cannot be made retroactively.