On September 9 Apple shipped the Xcode 27 RC and opened App Store submissions for the new OS releases. Buried in the same announcement: starting April 2027, the App Store will stop accepting builds made with older SDKs. If your CI is a couple of Mac minis under a desk, you know the ritual that kicks off — update macOS on the agents, update Xcode, rebuild everything that broke along the way. In Xcode Cloud, the new environment simply shows up in a dropdown: last fall, Xcode 26 became available there on release day, September 15.
A good moment, then, to finally take this cloud apart: what it is, what it costs, and where its abilities end. Spoiler on that last part: they end exactly at the border of the Apple ecosystem, and living with that border in a company that also has a backend and an Android team is a separate article.
What it actually is#
Xcode Cloud is a managed CI/CD service built into Xcode and App Store Connect. You don't administer runners: builds run on Apple silicon in Apple's data centers, and macOS and Xcode versions are picked from a dropdown.
The unit of configuration is a workflow. It has four parts:
- start condition — a branch or tag change, a pull request, a schedule, or a manual run;
- environment — the Xcode and macOS versions (betas included);
- actions — build, test, analyze, archive; tests can run in parallel across several simulators;
- post-actions — TestFlight distribution, App Store submission, Slack notifications.
Supported git providers: GitHub, GitHub Enterprise, GitLab (self-managed included), Bitbucket. The first workflow is created from inside Xcode in a single dialog: Integrate → Create Workflow, and about fifteen minutes later you have your first cloud build — without a single YAML file and without negotiating whose desk the build machine will live on.
Since last year the entry bar dropped even lower: you can build and test without a paid Developer Program membership. TestFlight and publishing still require the account.
Code signing stops being a job#
The historical pain of iOS CI was never the compilation. It's signing: certificates, provisioning profiles, their quiet expiry, an encrypted repo for fastlane match, all of it. An entire class of tooling exists only because signing in CI is its own profession.
In Xcode Cloud that profession doesn't exist. Cloud signing creates and rotates certificates itself, profiles refresh without you, and the beloved "whose Mac has the distribution certificate?" disappears from the process. That is arguably the strongest argument for the whole service — stronger than the price.
Nice extras live in the same box: build statuses right in the GitHub pull request (you can make them required for merging), test and coverage reports inside Xcode itself, TestFlight distribution as a checkbox in the workflow settings.
The economics#
Since January 2024, the Developer Program membership ($99/year) includes 25 compute hours per month. Beyond that, paid tiers:
| Tier | Price | Per hour |
|---|---|---|
| 25 hours | included in membership | — |
| 100 hours | $50/mo | $0.50 |
| 250 hours | $100/mo | $0.40 |
| 1000 hours | $400/mo | $0.40 |
For contrast: a macOS runner on GitHub Actions costs $0.08 per minute — $4.80 per hour, nearly an order of magnitude more. The comparison isn't entirely fair: the hardware differs, and parallel test destinations in Xcode Cloud burn hours simultaneously. Even with those corrections, Apple's cloud is one of the cheapest macOS builds on the market.
Unused hours expire at the end of the month. A back-of-the-envelope check on a real project: a build with tests takes 12–15 minutes, so the free 25 hours cover roughly a hundred runs. For a solo developer, plenty. For a five-person team with CI on every push, about a week.
Where it hurts#
Now the honest "against" column, without which the picture means nothing.
Apple ecosystem only. iOS, iPadOS, macOS, watchOS, tvOS, visionOS — and that's it. No backend, no Android, no Docker, no Linux. Xcode Cloud will not become your company's CI — only your iOS team's CI.
Customization is three scripts. Everything beyond the standard actions lives in ci_scripts/: ci_post_clone.sh, ci_pre_xcodebuild.sh, ci_post_xcodebuild.sh. There is no arbitrary step graph like in GitHub Actions. SPM dependencies resolve out of the box; CocoaPods and custom tooling are on you, via post-clone and Homebrew.
Configuration doesn't live in git. Workflows are configured in App Store Connect, not in a file next to the code. The API can read and create them, but "config as code" is something you build yourself — it doesn't ship with the product.
Apple dictates the environment versions. In December, Xcode Cloud had a known bug: export archive for development distribution failed on Xcode 26.2, and the official workaround was "build on 26.1". Apple does the fixing — but Apple also picks the timeline, not you. Add queues: before major Apple releases, builds sit noticeably longer waiting for capacity.
Secrets and policy. Secrets are environment variables in the App Store Connect UI. No Vault integration, no self-hosted runners, ever: if your security team requires "builds never leave the perimeter", the conversation ends at this bullet.
Who should say yes, who should say no#
Solo developers and teams up to ~5 iOS engineers with a purely Apple product — yes, almost without hesitation. The free hours are enough, signing vanishes as a category of work, TestFlight is two clicks away, and the cost of owning a pair of aging Mac minis is usually underestimated right up until the April App Store deadlines.
Teams with hard reproducibility requirements, custom step graphs, secrets in Vault and an "everything stays in the perimeter" policy — no. Or, more interestingly, a hybrid: the company's shared pipeline stays where it is, and Xcode Cloud becomes one specialized worker inside it — building and shipping the iOS app.
How that hybrid is wired in practice — triggering builds through the App Store Connect API, webhooks back into the pipeline, artifacts and monorepos — is what the next article covers.
