25.2 · CI/CD tools, versioning and designing the pipeline

A release should be a button, not a ritual. The pipeline builds the same way every time, signs without a human, versions without a spreadsheet, and promotes one tested artefact instead of rebuilding.

Mental model. Build once, test that build, promote it. Everything environment-specific (secrets, version numbers, endpoints) comes in from outside the code.

The tools

Xcode Cloud, GitHub Actions, Fastlane and the command line underneath all of them.

  1. What are the main ways to run iOS CI/CD (Xcode Cloud, GitHub Actions, Fastlane, others), and what do they all call underneath? 25.2.1 · L3
    Every option ends in the same command-line tools, so learn those first. xcodebuild builds and tests (build-for-testing, test-without-building), and releases…

Version numbers

Marketing versions, build numbers and how they are produced.

  1. How do marketing versions and build numbers work, how should CI generate them, and which rules does App Store Connect enforce? 25.2.2 · L3
    Two numbers identify a build, and they have different jobs. CFBundleShortVersionString is the marketing version users see (“2.4.0”), three period-separated…

Pipeline design

Hermetic builds, secrets, caching and artefact promotion.

  1. How do you design a release pipeline: hermetic builds, secrets, caching, artefact promotion and the order of stages? 25.2.3 · L5
    Design the pipeline around one artefact. A commit triggers a build that produces a signed archive once; the same archive is then tested, uploaded to TestFlight…

More in App Store & release engineering