Tuist vs XcodeGen：2026 プロジェクト生成をどう選ぶか

Xcodeプロジェクトの差分が頻発し、手動編集した設定をCIで再現できない。
最短の解決策は、小規模ならXcodeGen、複数プロジェクトと共通規約が必要ならTuistを選び、判断が曖昧なら隔離した遠隔Macで同じリポジトリを二軌道検証することです。

このガイドは、手作業で.xcodeprojを管理している個人開発者や小規模チーム向けです。複数のTargetやSchemeを統一したいiOS/macOSチーム、遠隔Mac CIのツールバージョンと再現性を管理するDevOps・開発基盤担当者にも使える判断基準をまとめます。

TuistとXcodeGenの主な違い

プロジェクト生成ツールを選ぶとき、最初に「.xcodeprojを生成できるか」だけを見ると判断を誤ります。重要なのは、生成後の規約、依存関係、CI上の責任をどこまでツールに持たせるかです。

XcodeGenはYAMLまたはJSONでTarget、Scheme、Build Settingsなどを記述し、Xcodeプロジェクトを生成する構成が中心です。詳細な項目はXcodeGen公式のProject Specで確認できます。

TuistはSwift Manifestを使い、共通の補助コードをチーム内で共有できます。複数プロジェクトに同じTargetテンプレートや命名規約を適用したい場合は、Tuistの共有コードに関する公式ドキュメントが判断材料になります。

この表の評価は性能順位ではなく、運用責任との適合度です。両方とも依存管理、署名、Xcodeのビルド実行をすべて自動的に引き受ける製品ではありません。生成、依存解決、xcodebuild、CIノード管理を分けて考えてください。

小規模チームの選択：XcodeGenか現状維持か

単一アプリでTarget数が少なく、手動変更の衝突を減らしたいなら、まずXcodeGenを候補にします。特に「設定をファイルでレビューしたいが、大きな開発基盤はまだ必要ない」というチームでは、導入範囲を限定しやすい点が利点です。

ただし、空のサンプルプロジェクトが生成できるだけでは不十分です。既存のCocoaPods、Swift Package、Build Phase、署名設定、環境別Schemeを同じリポジトリで表現できるかを確認します。XcodeGenの基本的な利用方法は公式リポジトリのREADMEで照合できます。

次の条件なら、XcodeGenを選ぶ判断がしやすくなります。

• 変更をレビューする担当者が少なく、YAMLまたはJSONを読める。
• 既存のTargetとSchemeを大きく再設計せず、生成へ移したい。
• 依存関係の管理はSwift PackageやCocoaPodsなど既存の仕組みで足りる。
• CIで必要なのは、固定した手順で生成してからxcodebuildを実行すること。
• 生成失敗時に、従来のプロジェクトへ戻す担当者が決まっている。

反対に、署名やScriptが複雑で、誰も生成定義を保守できないなら、すぐに置き換えない方が安全です。既存の.xcodeprojをGitに残すかどうかは、生成が完全に再現できるかで決めます。生成物をコミットしない運用にする場合でも、全員が同じツールと設定で再生成でき、差分を確認できることが前提です。

注意：生成ファイルをGitから外す判断は、設定ファイルを追加した時点ではなく、クリーンなクローンから同じSchemeを再生成し、ビルドできた後に行ってください。

モジュール化チームの選択：Tuistの統制範囲

複数アプリ、共有モジュール、同じ形のTargetが増えているなら、Tuistを評価する価値があります。Swiftで共通の補助コードを整理できるため、プロジェクトごとに似た設定を複製するより、規約の変更箇所を集約しやすくなります。

一方で、キャッシュや選択的テストのような拡張機能を理由に導入を決めるのは危険です。まずManifestから安定したプロジェクトを生成できること、依存関係とSchemeを開発者環境とCIで一致させられることを確認します。最適化機能は、基本生成と完全なビルドが通った後に別の判断として扱います。

「XcodeGenからTuistへ移行する価値があるか」は、機能数ではなく次の差で決まります。

Tuistを採用するなら、共通コードの所有者、Manifestのレビュー担当、ツール更新の周期を決めてください。そこが未定のままでは、手動のプロジェクト差分がSwiftコードの差分に置き換わるだけです。

CI担当者の確認：遠隔Macでの再現境界

プロジェクト生成ツールをCIへ接続するとき、開発者のMacで成功した事実は結論になりません。新しいクローン、固定したツール、非対話の生成、依存解決、Schemeの可視性、Archiveまでを同じノードで確認します。

Appleのxcodebuildコマンドラインリファレンスを基準に、生成ツールの責任とXcodeのビルド責任を分離してください。TuistのCI向け公式ガイドも、継続的インテグレーションへの接続方法を確認する資料になります。

実装は次の順で進めます。

1. 現行ブランチで、Xcodeのバージョン、依存定義、署名方式、必要な環境変数を記録します。
2. 独立ブランチにXcodeGen版とTuist版の定義を作り、PROJECT_NAME、TEAM_ID、SIGNING_PROFILEなどのプレースホルダーを使います。
3. 同じコミットをクリーンな遠隔Macへ取得し、ツールを固定した状態でプロジェクトを生成します。
4. 生成されたTargetとSchemeを確認し、依存解決、テスト、Archiveを非対話で実行します。
5. 生成物の差分、Derived Dataやキャッシュの扱い、ログ、終了コードを保存します。
6. ノードを再起動して同じ処理を繰り返し、資格情報や一時ファイルに依存していないか確認します。
7. 署名、Script、第三者依存のどれかが安定しない場合は本番置換を停止し、現行プロジェクトへ戻せる状態を残します。

遠隔MacをCIノードとして使う場合は、ツールだけでなくXcodeの導入状態、Homebrewなどの補助ツール、秘密情報、再起動後の復旧も管理対象です。必要であれば、Macの実機と仮想環境の違いを確認し、署名やSimulator検証に必要な環境を先に切り分けてください。

移行責任者の二軌道検証

境界が曖昧なプロジェクトでは、現在の本番用.xcodeprojを先に削除しないでください。現行構成を保存し、別ブランチまたは破棄可能な遠隔Mac上で、同じコミットからTuistとXcodeGenをそれぞれ生成します。

比較するのは設定ファイルの行数ではありません。次の観測結果を同じ形式で残します。

• Target、Scheme、Build Configurationの差分
• クリーンなクローンからの生成結果
• 依存解決とテストの終了コード
• Archiveと署名処理の成否
• ブランチを切り替えた後の再生成結果
• ノード再起動後の再実行結果
• 失敗時に現行工程へ戻せるか

「小型iOSプロジェクトならTuistかXcodeGenか」という判断は、上の検証でXcodeGenが十分な表現力を持ち、Tuistの共通化がまだ不要ならXcodeGenに寄せます。逆に、複数の開発チームが同じ規約を使い、Target追加のたびに重複設定が増えるならTuistを選びます。どちらにも決められない場合は、期限を区切った二軌道試行にし、成功条件と停止条件を先に文書化してください。

手元に予備のMacがない場合、短期間だけ再構築できるMacノードを用意すると、同じリポジトリで生成、ビルド、テスト、復旧まで確認できます。MacDateのMacレンタル料金ガイドで利用形態を確認し、長期契約を先に決めるのではなく、移行判定に必要な期間と作業を切り分けてください。

最終判断とMac環境の使い分け

判断を一文にすると、単一アプリ、小規模チーム、低い移行予算ならXcodeGenです。複数プロジェクト、深いモジュール化、共通の工程規約が必要な開発基盤チームならTuistを評価します。既存工程が安定しているのに保守担当者がいないなら、どちらも急いで採用せず、現状維持を選ぶ方が安全です。

いま使っている開発環境がLinuxやWindows中心の場合、Xcode実行、署名、Simulator、Archiveを同じ場所で再現しにくいという欠点があります。手元のMacを常時稼働させる方法もありますが、更新、停電、再起動、アクセス権限を自分で管理しなければなりません。

そのため、移行の判定だけにMacが必要なら、MacDateのようなレンタルMacを短期間の検証ノードとして使う方が、購入前に失敗条件を確認できます。長期的に固定負荷を処理するチームや物理機器への直接アクセスが必要な場合は自前のMacが適しますが、二軌道の生成とCI復旧を試す段階では、再構築できる遠隔Macの方が判断を戻しやすい選択です。