Xcode Cloud でビルド、配信、自動化する

ハイライト

Xcode Cloud はネイティブな複数リポジトリ対応と Onboarding Assistant を追加し、iOS チームが自前の CI/CD 基盤を保守しなくても、ビルド、テスト、TestFlight 配信まで行えるようにします。

主要内容

以前の問題

iOS チームが継続的インテグレーションを行う場合、よくある流れは Mac mini を買ってファームを組み、証明書を設定し、GitHub Actions や Jenkins のスクリプトを書くことでした。Xcode Cloud の登場でこの流れは簡単になりましたが、複数リポジトリのプロジェクトはまだ悩みの種でした。

具体的な痛点は二つありました。一つ目はプライベート依存関係です。プロジェクトでは UI コンポーネントライブラリやネットワーク層を独立した Git リポジトリに分け、Swift Package Manager (SPM) で取り込むことがよくあります。以前の Xcode Cloud はメインリポジトリしか取得できなかったため、プライベートな SPM 依存関係の取得に失敗することがありました。開発者は ci_post_clone.sh に SSH key を注入して手動で clone する必要があり、スクリプトは見通しが悪く、権限問題でビルドが不安定に失敗しました。

二つ目は配信設定の煩雑さです。TestFlight 配信では App Store Connect の Web 画面へ移動して操作する必要があり、Xcode 内の開発フローから分断されていました。

Apple が行ったこと

今年 Apple はまったく新しい CI ツールを発表したのではなく、Xcode Cloud の中で三つの的を絞った改善を行いました。

Onboarding Assistant。 Xcode の Report Navigator に視覚的なガイドが追加され、数クリックで iOS と macOS アプリをクラウドビルドへ接続できます。App Store Connect で手動でプロジェクトを作成し、ワークフローを設定する必要はありません。

Additional repositories のネイティブ対応。 Xcode Cloud の Workflow 設定で、複数の Git リポジトリを直接接続できます。プライベートなコンポーネントライブラリや社内ツールリポジトリは、UI 上でアクセス権限を設定でき、ビルド時に自動で取得されます。ci_post_clone.sh は、単純な環境変数を扱う本来の役割へ戻れます。

Webhook イベント配信。 Xcode Cloud はビルド状態イベントを外部 URL へ送信できます。Payload は標準 JSON で、ビルド番号、ワークフロー名、状態、TestFlight リンクを含みます。企業チームは Apple 固有の CI 構文を学ばなくても、社内システムへ接続できます。

これらの改善が解決すること

50人未満程度の中小チームは、多くの一般的なアプリ開発フローで Jenkins や GitHub Actions を保守する必要がなくなります。複数リポジトリプロジェクトのプライベート依存関係設定は、スクリプトの hack から UI のチェックへ移ります。ビルド状態は Slack、Lark、社内リリースシステムへ自動通知できます。

Apple は「運用不要」の体験で開発者をエコシステム内に留めています。独立開発者にとっては、インフラコストなしで完全な CI/CD パイプラインを持てるということです。

詳細

Additional repositories の設定と薄くなった post-clone スクリプト

(03:15)

Xcode Cloud の Workflow 設定では、“Additional repositories” セクションから複数の Git リポジトリを追加できます。各リポジトリは個別にアクセス権限を設定でき、ブランチマッチング戦略にも対応します。

設定が終わると、ci_post_clone.sh は複雑な SSH key や git clone ロジックを扱う必要がなくなります。

#!/bin/sh

# SPM キャッシュディレクトリを設定し、後続のビルドを高速化する
export SPM_CACHE_DIR="$CI_WORKSPACE/.spm_cache"
mkdir -p "$SPM_CACHE_DIR"

# Release ビルド用のコンパイルフラグを注入する
if [[ "$CI_WORKFLOW" == "Release" ]]; then
    export SWIFT_ACTIVE_COMPILATION_CONDITIONS="RELEASE_BUILD"
fi

重要な点：

CI_WORKSPACE は Xcode Cloud が注入する環境変数で、ビルド作業ディレクトリを指します
CI_WORKFLOW は現在実行中のワークフロー名を表し、条件分岐に使えます
スクリプトには実行権限が必要です（chmod +x ci_post_clone.sh）。ない場合、ビルドが静かに失敗することがあります
追加リポジトリを UI で設定すると、Xcode Cloud が自動で取得し、スクリプトで処理する必要はありません

ブランチマッチング戦略には注意が必要です。Xcode Cloud はデフォルトで、メインリポジトリと同名のブランチを取得しようとします。メインリポジトリが feature/login ブランチにあり、コンポーネントライブラリには main しかない場合、ビルドは失敗します。Workflow 設定で各追加リポジトリに Fallback ブランチを明示的に指定する必要があります。

Webhook イベントの受信と処理

(12:40)

Xcode Cloud の Webhook は、ビルドライフサイクルの各段階で発火します。Started、Building、Testing、Finished です。Payload の構造は次のようになります。

struct XcodeCloudPayload: Decodable {
    let buildNumber: String
    let workflowName: String
    let status: String // "SUCCEEDED", "FAILED", "STARTED"
    let testflightUrl: String?
}

func handleWebhook(_ payload: XcodeCloudPayload) async throws {
    guard payload.status == "SUCCEEDED" || payload.status == "FAILED" else {
        return // 中間状態は無視し、通知の連発を避ける
    }

    let emoji = payload.status == "SUCCEEDED" ? "✅" : "❌"
    let message = """
    \(emoji) Xcode Cloud ビルド通知
    ワークフロー: \(payload.workflowName)
    ビルド番号: \(payload.buildNumber)
    状態: \(payload.status)
    TestFlight: \(payload.testflightUrl ?? "なし")
    """

    try await sendMessageToChatApp(message)
}

重要な点：

中間状態をフィルタし、最終的な成功または失敗イベントだけを処理します
testflightUrl は、ビルドが成功し、配信が設定されている場合だけ存在します
同じビルドで Webhook が複数回届く可能性があるため、受信側は冪等に処理する必要があります
HTTP POST と標準 JSON を受け取れるバックエンドなら、専用 SDK なしで統合できます

TestFlight 配信の直結

(08:20)

Xcode 27 は IDE 内で直接、配信用 Workflow の設定と App Store Connect レコードの作成を行えます。流れは、対象アプリを選ぶ、ビルドワークフローを設定する、配信ステップを追加する、内部テストグループまたは外部テスターを選ぶ、というものです。全体の過程で App Store Connect の Web サイトをブラウザで開く必要はありません。

macOS アプリのシームレスな導入

(05:50)

同じ Xcode Workspace 内の iOS target と macOS target に、それぞれ独立した Workflow を作成できます。クロスプラットフォームチームは、プラットフォームごとに独立した CI 設定を保守する必要がなくなります。

重要な示唆

1. ビルド状態通知 bot を作る

何をするか：Vapor または Hummingbird で軽量なサーバーを作り、Xcode Cloud Webhook を受け取り、ビルド結果をチームのチャットツールへ送ります。

なぜ価値があるか：Xcode Cloud の Webhook はビルド完了時に標準 JSON を送信し、ビルド番号、状態、TestFlight リンクを含みます。チームは Xcode や App Store Connect を見張らなくても、ビルドの成功や失敗をリアルタイムで把握できます。

どう始めるか：Xcode Cloud の Workflow 設定ページで Webhook URL を設定し、自分のサーバーを指定します。サーバー側で status フィールドを解析し、CI_WORKFLOW 環境変数と組み合わせて、ブランチごとの通知を別々のチャンネルへ送ります。中間状態をフィルタし、SUCCEEDED と FAILED だけを処理します。

2. 社内コンポーネントライブラリを Xcode Cloud のネイティブ依存関係へ移す

何をするか：ci_post_clone.sh で手動 clone しているプライベートリポジトリを棚卸しし、Xcode Cloud の Additional repositories へ一つずつ移行します。

なぜ価値があるか：以前はプライベートな SPM 依存関係に、SSH key を注入するスクリプトが必要で、権限問題によってビルドがランダムに失敗していました。ネイティブ対応後は、リポジトリアクセスを UI で設定でき、post-clone スクリプトは環境変数の処理へ戻り、ビルド安定性が大きく向上します。

どう始めるか：Xcode -> Report Navigator -> Workflow を選択 -> Edit -> Additional repositories を開き、依存リポジトリを一つずつ追加してアクセス権限を設定します。メインリポジトリが feature ブランチにあるときでもコンポーネントライブラリを取得できるよう、各リポジトリに Fallback ブランチを設定してください。

3. 独立開発者向けに全自動リリースパイプラインを設定する

何をするか：コード push から TestFlight 配信までを無人化し、一人でも完全な CI/CD を持てるようにします。

なぜ価値があるか：Xcode Cloud の Onboarding Assistant により、運用経験がない開発者でも数分でビルドワークフローを設定できます。TestFlight 直結配信と組み合わせれば、独立開発者は Mac mini ファームや GitHub Actions スクリプトを必要としません。

どう始めるか：Onboarding Assistant で Workflow を作成し、コード push をトリガーにする -> 単体テストを実行する -> Archive する -> TestFlight の内部テストグループへ自動アップロードする、という流れを設定します。さらに Webhook を追加し、ビルド結果を個人の通知チャンネルへ送ります。

4. ephemeral VM を安全性とコンプライアンス監査に活用する

何をするか：Apple のビルド仮想マシンの安全性を、チームのセキュリティ監査文書に記載します。

なぜ価値があるか：金融や医療系アプリのソースコードと証明書は非常に機密性が高いものです。Apple は Xcode Cloud のビルド仮想マシンが使用後に破棄され、ソースコードを永続化しないと説明しており、自前 Jenkins やサードパーティ CI よりもセキュリティ監査を通しやすくなります。

どう始めるか：Xcode Cloud ドキュメントの Security セクションで該当する約束事項を確認し、チームのコンプライアンス文書へ引用します。自前 CI の運用コストとセキュリティリスクを比較し、Xcode Cloud を使うコンプライアンス上の利点を定量化します。

5. クロスプラットフォームアプリ向けに統一ビルドマトリクスを設定する

何をするか：同じ Xcode Workspace 内で iOS target と macOS target にそれぞれ独立した Workflow を作り、ビルド設定は共有します。

なぜ価値があるか：クロスプラットフォームチームは以前、プラットフォームごとに独立した CI 設定を保守する必要があり、変更時に漏れが起きがちでした。Xcode Cloud は同じ Workspace 内の複数 target に別々の Workflow を作れるため、設定を集中管理でき、保守コストを半減できます。

どう始めるか：Xcode Cloud で iOS target 用の Workflow を作成し、次に macOS target 用の Workflow を作成します。二つの Workflow は同じ post-clone スクリプトとテスト設定を共有でき、Archive と配信ステップだけをプラットフォームごとに分けます。入口は Xcode -> Report Navigator -> プロジェクトを選択 -> Create New Workflow です。