9月9日、AppleはXcode 27 RCを公開し、新OS向けアプリの審査受付を開始した。同じ発表の隅にはこうある：2027年4月以降、古いSDKでビルドされたアプリはApp Storeで受け付けられなくなる。CIが机の下のMac mini 2台という体制なら、これから始まる儀式はおなじみだろう。エージェントのmacOSを更新し、Xcodeを更新し、その過程で壊れたものを全部ビルドし直す。Xcode Cloudでは、新しい環境はドロップダウンに現れるだけだ。昨秋、Xcode 26はリリース当日の9月15日にXcode Cloudで利用可能になった。
というわけで、このクラウドを一度きちんと分解してみる良い機会だ。何なのか、いくらかかるのか、そして能力の限界はどこか。最後の点を先に言ってしまうと、限界はAppleエコシステムの境界線とぴったり一致する。バックエンドとAndroidチームを抱える会社でその境界線とどう付き合うかは、別の記事で扱う。
そもそも何なのか#
Xcode CloudはXcodeとApp Store Connectに組み込まれたマネージドCI/CDだ。ランナーの管理は不要で、ビルドはAppleのデータセンター内のApple silicon上で動き、macOSとXcodeのバージョンはドロップダウンから選ぶ。
設定の単位はworkflow。構成要素は4つある。
- 開始条件 — ブランチやタグの変更、pull request、スケジュール、手動実行
- 環境 — XcodeとmacOSのバージョン（ベータ版を含む）
- アクション — build、test、analyze、archive。テストは複数シミュレータで並列実行できる
- ポストアクション — TestFlight配布、App Store提出、Slack通知
対応するgitプロバイダはGitHub、GitHub Enterprise、GitLab（self-managed含む）、Bitbucket。最初のworkflowはXcode内のダイアログひとつで作れる：Integrate → Create Workflow。15分ほどで最初のクラウドビルドが手に入る。YAMLファイルは一切なし、ビルドマシンを誰の机に置くかの交渉もなしだ。
昨年からは入り口のハードルがさらに下がり、有料のDeveloper Programに加入しなくてもビルドとテストができるようになった。TestFlightと公開には引き続きアカウントが必要になる。
署名が仕事でなくなる#
iOS CIの歴史的な痛みはコンパイルではなかった。署名だ。証明書、provisioning profile、その静かな失効、fastlane matchのための暗号化リポジトリ、その他もろもろ。CIでの署名がひとつの専門職になっているからこそ、ツールのジャンルが丸ごと存在している。
Xcode Cloudにはその専門職がない。Cloud signingが証明書を自動で作成・ローテーションし、プロファイルは勝手に更新され、「配布用証明書が入ってるのは誰のMacだっけ？」というお決まりの一言がプロセスから消える。これがおそらくサービス全体で最も強い論拠だ。価格よりも強い。
同じ箱にうれしいおまけも入っている：GitHubのpull requestに直接表示されるビルドステータス（mergeの必須条件にもできる）、Xcode内で見られるテストとカバレッジのレポート、workflow設定のチェックボックスひとつで済むTestFlight配布。
経済性#
2024年1月以降、Developer Programのメンバーシップ（年間$99）には月25コンピュート時間が含まれる。それ以上は有料プランだ。
| プラン | 料金 | 時間あたり |
|---|---|---|
| 25時間 | メンバーシップに込み | — |
| 100時間 | $50/月 | $0.50 |
| 250時間 | $100/月 | $0.40 |
| 1000時間 | $400/月 | $0.40 |
比較のために：GitHub ActionsのmacOSランナーは1分$0.08 — 1時間$4.80で、ほぼ一桁高い。この比較は完全にフェアではない。ハードウェアが違うし、Xcode Cloudの並列テストdestinationは時間を同時に消費する。それを差し引いても、Appleのクラウドは市場で最も安いmacOSビルドのひとつだ。
未使用の時間は月末に消滅する。実プロジェクトでの概算：テスト込みのビルドが12〜15分なら、無料の25時間でおよそ100回分。ソロ開発者には十分すぎる。push毎にCIを回す5人チームなら、1週間で尽きる。
痛いところ#
ここからは正直な「反対」の列。これがないと全体像に意味がない。
Appleエコシステムのみ。 iOS、iPadOS、macOS、watchOS、tvOS、visionOS — 以上。バックエンドもAndroidもDockerもLinuxもない。Xcode Cloudは会社のCIにはならない。iOSチームのCIになるだけだ。
カスタマイズはスクリプト3本。 標準アクションの外に出るものはすべてci_scripts/に住む：ci_post_clone.sh、ci_pre_xcodebuild.sh、ci_post_xcodebuild.sh。GitHub Actionsのような任意のステップグラフはない。SPM依存は素で解決されるが、CocoaPodsや独自ツールはpost-cloneとHomebrew経由で自力対応になる。
設定がgitに入らない。 WorkflowはApp Store Connect上で設定するもので、コードの隣のファイルではない。APIで読み書きはできるが、「config as code」は自分で組む必要がある。標準機能としては存在しない。
環境のバージョンはAppleが決める。 12月、Xcode Cloudには既知のバグがあった：Xcode 26.2でdevelopment配布向けのexport archiveが失敗し、公式のワークアラウンドは「26.1でビルドしてください」だった。直すのはAppleだが、いつ直すかを決めるのもAppleであって、あなたではない。さらにキューの問題もある：Appleの大型リリース前は、ビルドの待ち時間が目に見えて延びる。
シークレットとポリシー。 シークレットはApp Store Connect画面上の環境変数だ。Vault連携はなく、self-hostedランナーは存在しないし今後もない。セキュリティ部門の要件が「ビルドは境界の外に出さない」なら、この項目で話は終わる。
向いている人、向いていない人#
ソロ開発者と、純Apple製品を持つ〜5人程度のiOSチームには、ほぼ迷わず「はい」だ。無料時間で足りるし、署名が仕事のカテゴリごと消えるし、TestFlightは2クリック。老朽化していくMac mini 2台の維持コストは、App Storeの4月の締め切りが来るまで過小評価されがちだ。
再現性への厳しい要件、独自のステップグラフ、Vaultのシークレット、「すべて境界内」ポリシーを持つチームには「いいえ」。あるいは、より面白い選択肢としてハイブリッドがある。会社の共通パイプラインは今の場所に残し、Xcode Cloudはその中でひとつの役割 — iOSアプリのビルドと配布 — を担う実行者になる。
そのハイブリッドを技術的にどう配線するか — App Store Connect APIでのビルド起動、パイプラインへのwebhook、アーティファクト、モノレポ — は次の記事で扱う。
