Xcode Cloud vs GitHub Actions：2026年のiOSビルドをどう選ぶか

2026年9月2日時点で、Xcode 27はまだBetaとして案内されています。AppleのXcode 27リリースノートを基準に、CI環境の対応状況を確認してください。

症状：Apple標準のiOSプロジェクトは早く自動化したいが、runnerの保守はしたくない。
最短解：原生構成ならXcode Cloud、私有ネットワーク・特殊な依存関係・永続環境が必要ならGitHub Actionsの自托管Mac runnerを選びます。検査を簡単にしつつ公開環境を制御したい場合は、両者を組み合わせます。

このページは、Appleプラットフォームのプロジェクトを一つか二つ運用し、CIの管理作業を減らしたい個人開発者向けです。FlutterやReact Native、独自スクリプトを含むプロジェクト、小規模チームの署名・TestFlight運用にも対応します。

先に比較：Xcode CloudとGitHub Actionsは同じ「CI」ではありません

Xcode Cloud、GitHubが用意するmacOS runner、GitHub Actionsの自托管Mac runnerは、YAMLの書き方が違うだけの選択肢ではありません。ビルド環境、キャッシュ、ネットワーク、認証情報、再起動後の復旧を、誰がどこまで管理するかが異なります。

Xcode Cloudのワークフローは、ビルド、テスト、アーカイブ、配布などをAppleの開発フローに沿って組み立てる方式です。Xcode Cloudの概要とワークフローアクションの仕様を確認すると、Apple標準のプロジェクトをどこまで移行できるか判断しやすくなります。

個人開発者：手間を減らすならXcode Cloudから始める

Xcode、Swift Package Manager、標準の自動署名、TestFlightだけを使う個人プロジェクトなら、最初の候補はXcode Cloudです。リポジトリ接続からビルド、テスト、アーカイブ、配布までの経路がAppleのツールチェーンに近く、Mac上で手作業を続けるより移行範囲を絞れます。

ただし、「Apple製品だから必ず動く」とは考えないでください。次の3点を先に確認します。

• Archive対象のSchemeが共有され、CIで選択できること。
• 私有SwiftパッケージやGit依存関係に、ビルド環境からアクセスできること。
• ビルド前後のスクリプトが、対話入力なしで完了すること。

私有依存関係については、Xcode Cloudで依存関係を利用可能にするAppleの説明に沿って認証方法を確認してください。ローカルのKeychainや開発者のログイン状態に依存する構成は、そのままでは再現性がありません。

独立開発者がXcode CloudとGitHub Actionsのどちらを選ぶと手間が少ないかは、ワークフローの記述量では決まりません。runnerのOS更新、Xcode更新、容量不足、証明書の入れ替え、失敗後の再起動を自分で担当したくないなら、まずXcode Cloudで標準経路を固める方が安全です。

Xcode CloudはFlutterやReact Nativeにも向くのか

FlutterやReact Nativeでも利用できる可能性はありますが、フレームワーク名だけで判断しないでください。Node、Ruby、CocoaPods、パッケージマネージャー、生成スクリプト、環境変数までを毎回クリーンな環境で再現できるかが判断材料です。

特に、次のような構成では自托管Mac runnerが有利です。

• 特定のNodeやRubyを長期間固定したい。
• 大きな依存関係を毎回取得せず、ローカルキャッシュを維持したい。
• 生成されたiOSプロジェクトを対話的に調査したい。
• 社内ネットワーク上のAPIやアーティファクトに接続する必要がある。

一方、依存関係をロックファイルで固定し、セットアップをスクリプト化できるなら、マネージド環境でも成立します。FlutterやReact Nativeだから自托管、という決め方ではなく、無署名ビルドとArchiveを同じ条件で試してください。

クロスプラットフォーム開発者：依存関係の再現性で分ける

GitHub Actionsの自托管runnerは、指定したMac上で必要なXcodeや補助ツールを維持できます。自托管runnerをワークフローで使う公式手順の通り、ラベルやrunner groupによってジョブの割り当てを制御できます。

これは自由度の代わりに運用責任を引き受ける選択です。具体的には次の負担が発生します。

• macOS、Xcode、Homebrew、Node、Rubyの更新計画。
• runner停止時の再起動とジョブ再実行。
• キャッシュ破損や空き容量不足の検知。
• 署名証明書、秘密鍵、APIキーの保護。
• 複数ジョブが同じ作業ディレクトリやKeychainを使わないための隔離。

GitHubのrunnerは、ジョブがどの環境へ送られるかをラベルやグループで決めます。runnerのルーティング仕様を確認し、公開用ジョブが意図しないMacへ流れないようにしてください。

どの時点で自托管Mac runnerへ移すべきか

次の信号が一つでも継続するなら、自托管環境を検討します。

• クリーンな環境で毎回同じ依存関係の取得に失敗する。
• 標準環境にないツールや特定バージョンが必要になる。
• 社内ネットワーク、VPN、プライベートなパッケージ置き場へ接続する。
• 手動Archiveでは成功するが、CIでは環境差分の調査が難しい。
• ビルド後に保持したいキャッシュや生成物が明確にある。

ただし、runnerをMacに置くだけでは解決しません。長時間停止した場合に誰が復旧するか、Xcode更新後にどのテストを再実行するか、秘密情報を持つジョブをどのブランチから許可するかまで決めてから移行してください。

小規模チーム：ビルド成功より権限分離を先に決める

複数人で運用する場合、Archiveできることだけを成功条件にすると危険です。リポジトリの編集権限、ワークフロー変更権限、署名資格情報、TestFlightへの公開権限を分けて設計します。

テスト用ジョブと署名・公開用ジョブは分離してください。公開処理は保護したブランチや承認済みの操作だけから起動し、外部から取り込んだコードを秘密情報へ直接触れさせない構成にします。GitHubの安全なActions利用ガイドでも、信頼できない入力と資格情報を同じ実行環境に置くリスクが説明されています。

自托管runnerを使う場合は、runner groupのアクセス制御も確認します。runner groupの権限設定で、どのリポジトリやワークフローが対象Macを使えるかを限定してください。公開リポジトリや外部コントリビューターのコードを、署名キーを保持するrunnerで無条件に実行する設計は避けます。

GitHub Actionsで自動署名し、iOS AppをApp Store Connectへアップロードすること自体は可能です。ただし、署名方式、証明書、プロファイル、APIキーの保管をワークフローに組み込む必要があります。アップロード後のビルド確認は、App Store ConnectへビルドをアップロードするAppleの手順に沿って、処理完了までを公開成功と定義してください。

Xcode CloudとGitHub Actionsを同時に使う双軌構成

両者を併用することはできます。役割を曖昧にせず、Xcode Cloudを標準テスト、自托管Mac runnerを特殊な依存関係や公開処理に割り当てる構成が分かりやすいです。

例えば、プルリクエストでは署名なしのビルドとテストをマネージド環境で実行します。リリースブランチでは、固定したXcode、私有ネットワーク、公開用の署名資格情報を持つ自托管環境だけを使います。

この分け方には注意点もあります。二つの環境でXcode、SDK、依存関係のバージョンがずれると、検査は通ったのに公開用Archiveだけが失敗します。環境情報をログへ出し、ロックファイルとビルド設定を共有し、両方で無署名ビルドを定期的に比較してください。

Xcode 27を使う場合は、Beta段階のため、正式版と同じ安定性を前提にしないでください。対応するrunnerのラベルやイメージについては、GitHubのmacOS larger runner資料とAppleのリリースノートを公開前に再確認します。

第一歩：壊さずに選ぶための双軌検証

いきなり既存の公開処理を移す必要はありません。次の順番で、署名なしビルドから検証します。

1. 同じコミットをXcode CloudとGitHub Actionsの両方へ渡します。
2. まず無署名のビルドと単体テストだけを実行します。
3. 次に私有依存関係、NodeやRubyなどの補助ツール、生成スクリプトを追加します。
4. Archiveと署名を別ジョブで試し、KeychainやAPIキーの扱いを確認します。
5. TestFlight向けのアップロードを限定したブランチで実行します。
6. runnerを再起動または初期状態に戻し、復旧手順とログの十分性を確認します。

比較するのは成功・失敗だけではありません。冷起動から完了までの所要時間、手動介入の箇所、依存関係の取得失敗、ログから原因を追えるか、環境を再構築できるかを記録します。速度や費用を根拠なく比較せず、あなたのプロジェクトの実測結果で決めてください。

選定前の可否チェック

• [ ] SchemeをCI上でArchive対象として選択できる。
• [ ] 私有依存関係の認証方法を文書化した。
• [ ] Xcodeと補助ツールのバージョンを固定した。
• [ ] 無署名ビルドと署名済みArchiveを別ジョブにした。
• [ ] App Store Connectの資格情報を公開ログへ出さない。
• [ ] 外部コードが公開用runnerへ到達しない権限設定にした。
• [ ] runner停止後の再起動担当と復旧手順を決めた。
• [ ] Xcode 27 Betaを使う場合、正式版との差分を確認した。
• [ ] 2つの環境で同一コミットを検証し、手動介入点を記録した。

このチェックで標準項目だけが残るなら、Xcode Cloudを維持する判断が自然です。私有ネットワーク、特殊な依存関係、持続キャッシュ、独自の公開スクリプトが残るなら、自托管Mac runnerへ寄せます。検査と公開で要件が違うなら、双軌構成を選びます。

現在の環境からMacへ移すべきケース

WindowsやLinux上のスクリプト、共有サーバー、断続的な手動Archiveで運用している場合、問題は単にmacOSがないことではありません。Xcodeを実行できない、署名用Keychainを安定して管理できない、App Store Connectへの公開作業が担当者の手元に残る、という分断が起きます。

自前のMacを購入すれば環境を固定できますが、CI専用機の保守、電源・回線、故障時の交換、不要な期間の遊休が負担になります。クラウドのマネージド環境だけでは、私有依存関係や特殊なツールチェーンを吸収しにくい場合があります。

そのため、自托管runnerを選んだものの物理Macの購入と保守まで抱えたくないなら、まずMacHTMLのコンソール利用方法で短期環境を使い、無署名ビルド、依存関係、Xcodeのバージョン、再起動後の復旧を確認する方法があります。運用前にはMacHTMLのヘルプで接続と利用条件も確認してください。

長期にわたり安定した高負荷処理を続ける場合、物理Macの常設や専用環境の方が適することもあります。反対に、移行実験、リリース前の検証、短期間のCI増強では、必要な期間だけMacを借りる方が、購入後の遊休や初期構築を避けやすい選択です。自托管構成を試す場合は、MacHTMLの料金プランを確認し、署名処理を移す前に検証用として使ってください。

現在の手動Archiveや一般的な共有環境を使い続けると、担当者のMacに依存し、証明書の状態が見えにくく、公開作業が属人化しやすくなります。MacHTMLのMacを短期レンタルして自托管runnerの候補環境を再現すれば、購入前に依存関係と復旧手順を確認できます。CIの検査とTestFlight公開を安全に分けられる見通しが立った時点で、初めて本番移行を判断してください。