Flutter個人開発にXcode Cloudは必要？GitHub Actionsとの使い分けを整理

FlutterでiOSアプリを何度かリリースしていると、ArchiveしてTestFlightへアップロードする作業を自動化したくなる。一方で、PRごとの flutter analyze やテストも自動化したい。そこで候補になるのが、AppleのXcode Cloudと、GitHubのGitHub Actionsだ。

「どっちが必要か」で比べると答えが出にくい。得意な仕事が違う。

先に結論

Flutter個人開発なら、どちらか一方に全部寄せる必要はない。

PRごとの flutter analyze / テスト / Android向けの確認 → GitHub Actions
iOSの署名からTestFlight配信 → Xcode Cloud

という併用が現実的だ。Xcode Cloudは「必須」ではない。すでにApple Developer Programに入っていて、手動のArchiveとアップロードに時間を取られているなら、試す価値がある、という位置づけになる。

何を比べているのか

どちらも「リポジトリの変更をきっかけに、ビルドやテストを自動で走らせる」仕組みだ。ただし前提が違う。

	Xcode Cloud	GitHub Actions
主な舞台	Appleプラットフォーム向けのビルドと配信	Linux / Windows / macOS を選んで任意のジョブ
設定の置き場	Xcode / App Store Connect側のワークフロー	リポジトリ内の YAML
Flutterとの関係	公式ドキュメントでカスタムスクリプトが前提	ランナー上にFlutterを入れて好きなコマンドを実行
Android	対象外	同じリポジトリで扱える

Flutter公式のContinuous deliveryでも、Xcode Cloudは独立した節として扱われ、GitHub Actionsはfastlane連携の一例として並ぶ。最初から「どちらかが正解」ではない。

Xcode CloudにFlutter SDKは標準では入っていない

ここが、Swiftだけ書いてきた人との差だ。

FlutterのXcode Cloud手順は、一時的なビルド環境にはmacOSとXcodeに含まれるツール、加えてHomebrewがあると説明したうえで、リポジトリをcloneしたあとにFlutterを自分で入れる例を示している。具体的には ios/ci_scripts/ci_post_clone.sh で Flutter を git clone し、flutter precache --ios や flutter pub get、必要なら CocoaPods まで走らせる。

つまり「Xcode CloudをオンにしたらFlutterアプリがそのまま通る」ではない。初回はスクリプトとワークフローの調整がいる。Apple側のカスタムビルドスクリプトも、依存関係のインストールやビルド前後の処理をスクリプトで足す前提の機能だ。

調査前に分かりにくかったのはこの点だ。Xcode Cloudの強みは「ゼロ設定でFlutterが動くこと」ではなく、Appleの署名と配信の流れに乗りやすいことにある。

Apple Developer Programには一定のコンピュート時間が含まれる

Xcode Cloudの利用開始によると、利用には Xcode 15.0 以降と Apple Developer Program のメンバーシップが必要で、毎月25コンピューティング時間がメンバーシップに含まれる。未使用分の翌月繰り越しはない。足りなければ、100時間 / 49.99米ドル〜といった月額プランがある。

コンピューティング時間は、ビルドや自動テストなどクラウド上のタスクに使った時間だ。Appleの説明では、分析・アーカイブ・ビルドとテストを並列に走らせる、と書かれている。

個人開発で意味があるのは、「別途CIサービスを契約する前に、すでに払っているADPの枠で試せる」ことだ。最初から有料プランを前提にしなくてよい。

一方、GitHub Actionsは別の課金だ。公開リポジトリの標準ランナーは無料で使える。非公開リポジトリはプランに含まれる分数があり、超過分はランナー種別ごとの分課金になる。flutter analyze のような Linux ジョブは、iOS用のmacOSランナーより負担が軽いことが多い。

iOSの署名〜TestFlightはXcode Cloudが得意

Xcode Cloudの概要は、ビルド・並列テストに加えて、TestFlightとの連携や App Store Connect への組み込みを機能として挙げている。ワークフローから新しいビルドをテスターに届ける、という話が公式の製品説明に含まれている。

たとえば、手動でTestFlightへアップロードしていると、既存のビルド番号と重複してアップロードに失敗することがある。Flutter公式のXcode Cloud手順によると、Xcode Cloudは新しいワークフローのビルド番号をデフォルトで 1 から始め、成功したビルドごとに増やしていく。すでに高いビルド番号を使っているアプリでは、Next Build Numberを設定して既存番号と衝突しないようにする。CI側のビルド番号を使う構成にすれば、こうした番号管理も自動化できる。

GitHub Actionsでも、macOSランナー上で xcodebuild し、App Store Connect API や fastlane で TestFlight に上げる道はある。Flutter公式もfastlane経由の配信を案内している。ただしGitHub Actions側でTestFlight配信まで組む場合は、署名やApp Store Connectへの認証を含め、CI向けの設定を自分で構成する必要がある。構成次第で取り方はいくつもある。

個人開発で消耗しやすいのは、まさにこの層だ。Xcode Cloudは「YAMLが好きだから」ではなく、署名とTestFlightまでをAppleのツールチェーン側に寄せたいときに効く。

analyze / test / AndroidまでならGitHub Actionsが得意

FlutterアプリはiOSだけで終わらない。PRのたびに次を回したい、という需要がある。

flutter analyze
ユニットテスト
場合によっては Android のビルド確認

これらは Linux 上で足りることが多い。GitHub Actionsは OS をジョブごとに選べる。ランナーの選び方のとおり、ubuntu-latest のようなラベルで安価（または公開repoなら無料）なチェックを回せる。設定はリポジトリ内の YAML に残るので、クローンすれば再現しやすい。

Xcode Cloudに同じことを全部載せると、Androidが載らないうえ、PRごとの軽量チェックまでコンピュート時間を食う。月25時間は「無制限の日常チェック枠」ではない。

結局、個人開発ではどう分けるか

仕事を分けるとこうなる。

やりたいこと	向きやすい方	理由
PRごとに静的解析・テスト	GitHub Actions	Linuxで足りる。設定がリポジトリに残る
Androidの確認も含めたい	GitHub Actions	Xcode Cloudの範囲外
mainやタグからTestFlightへ	Xcode Cloud	署名〜配信をApple側に寄せやすい。ADPの25時間で試せる
まだストア未提出でローカル実行だけ	どちらも急がなくてよい	手動アップロードの痛みが先に来てからで足りる

Flutter個人開発なら、チェックはGitHub Actions、iOS配信はXcode Cloudという併用も有力だ。

「Xcode Cloudは必要か」への答えは、多くの場合こう言い換えられる。

必須ではない。ただしADPに入っていて、iOSの提出作業を自動化したいなら、無料枠の範囲で使う理由はある。日常の品質チェックまではGitHub Actionsに任せた方がバランスがよい。

いまの時点で自分で確かめる必要があること

記事の判断は公式ドキュメント上の役割分担までだ。次はプロジェクトごとに実測がいる。

ci_post_clone.sh 込みの1ビルドが、何分・何コンピューティング時間になるか
月25時間で、配信用ワークフローが何回まわるか
依存関係（とくに iOS のパッケージ解決）がクラウド上で安定するか

ここは推測で埋めない。1アプリだけ通して、App Store Connectの使用状況を見た方が早い。