Xcode 26のコンパイルが遅すぎる：2026年、リモートMacでどう高速化する？
Xcode 26のコンパイルが遅すぎる場合は、まずBuild Timing Summaryで処理時間を測定し、プロジェクト側の無駄を直してから、CPU・メモリ・ストレージの不足を判断します。DerivedDataの削除や、根拠のないリモートMacの上位構成への変更は、最初の対策にすべきではありません。
この内容は、毎日増分ビルドを繰り返し、コード変更から実行結果までの待ち時間を短くしたい独立開発者向けです。リモートMacでRelease Archive、テスト、CI/CDを運用しており、構成の増強を検討している小規模チームにも適しています。
計測結果で「遅い」の内訳を分ける
同じ「コンパイルが遅い」という症状でも、原因は同じではありません。初回ビルドならSwift Packageの取得やソース解析、増分ビルドなら依存関係やSwiftファイルの再コンパイル、Archiveならリンク・署名・スクリプトが待ち時間を作ることがあります。
Xcodeのレポートナビゲーターでは、ビルド記録を開いてBuild Timing Summaryを確認できます。コマンドラインでは、次のように対象を固定して記録します。
xcodebuild \
-workspace "<WORKSPACE_PATH>" \
-scheme "<SCHEME_NAME>" \
-configuration Debug \
-destination 'platform=iOS Simulator,name=<DEVICE_NAME>' \
-showBuildTimingSummary \
build
-showBuildTimingSummaryで処理別の時間を確認し、-resultBundlePath "<RESULT_BUNDLE_PATH>"を加えて結果を保存します。Appleの増分ビルドの速度改善に関する公式ドキュメントも、変更範囲と依存関係を確認してから改善する流れを示しています。
| 記録対象 | 固定する条件 | 見るべき遅延 |
|---|---|---|
| 初回ビルド | コミット、Scheme、構成、対象デバイス | 依存関係取得、生成処理、全体コンパイル |
| 増分ビルド | 小さな同一変更、同じDerivedData | 不要なTarget、Swiftファイル、スクリプト |
| Archive | Release構成、同じ署名設定 | リンク、シンボル処理、署名、アップロード前処理 |
| テスト | テスト対象、シミュレーター、並列設定 | アプリビルド、起動、テスト実行、再試行 |
一度だけの記録では判断しません。コードのコミット、Scheme、Build Configuration、実行先をそろえ、同じ作業を再実行できる状態にします。
注意：依存関係の初回ダウンロードをコンパイル時間に含めると、プロジェクトの遅さと取得経路の遅さを取り違えます。取得、解決、コンパイルを別々の記録として扱ってください。
増分開発ではキャッシュより依存関係を先に直す
日常の増分ビルドで重要なのは、変更していないTargetまで再構築されていないかです。アプリ本体、拡張機能、テストTarget、コード生成処理の依存関係を確認し、一つの小さな変更が無関係な処理を起動していないかを調べます。
特定のSwiftファイルだけ時間が長い場合は、型推論が複雑な式、過度に広い公開範囲、巨大なファイル、頻繁に再実行されるマクロやコード生成を候補にします。Appleのコード設計でビルド効率を改善する資料を基準に、変更前後で同じ増分ビルドを比較します。
DerivedDataはキャッシュ異常の切り分けには使えますが、常用の高速化手段ではありません。削除後は中間生成物を作り直すため、以降の増分ビルドが速くなるとは限らず、むしろ待ち時間が増えることがあります。
| 症状 | 先に確認する項目 | 判断 |
|---|---|---|
| 小変更で多くのTargetが動く | Target依存関係、Build Phases | プロジェクト構成を修正 |
| 特定ファイルだけ長い | 型推論、公開シンボル、ファイル分割 | コードを分割して再計測 |
| 毎回スクリプトが走る | 入出力、実行条件、生成物 | 差分実行の条件を見直す |
| キャッシュ削除後だけ遅い | DerivedDataの再生成 | 定型手順から外す |
Targetの設定や依存関係は、Appleの新しいTargetを構成する公式資料とも照合できます。
Archiveはコンパイル以外の処理を分離する
Debugの実行が速くても、Release Archiveだけが遅いことがあります。Archiveでは、依存関係の準備、ソースコンパイル、リンク、リソース処理、シンボル処理、署名、自作スクリプトを別々に見ます。合計時間だけを記録すると、改善すべき箇所が隠れます。
xcodebuild \
-workspace "<WORKSPACE_PATH>" \
-scheme "<SCHEME_NAME>" \
-configuration Release \
-archivePath "<ARCHIVE_PATH>" \
-showBuildTimingSummary \
archive
DebugとReleaseで設定を比較し、最適化、追加Target、シンボル生成、バージョン処理、署名関連のスクリプトを確認します。配布手順については、AppleのBeta版と正式版の配布ドキュメントが基準になります。
| DebugとReleaseの差 | 主な候補 | 対応方針 |
|---|---|---|
| コンパイルだけReleaseで増える | 最適化、型チェック、追加フラグ | 設定差分を確認 |
| リンクが長い | Target、ライブラリ、シンボル | 不要な構成を整理 |
| スクリプトが長い | 署名、画像処理、生成処理 | 入出力と再実行条件を計測 |
| Archive後半が長い | 署名、シンボル、配布準備 | コンパイル時間と分離 |
ここで初めてハードウェアを評価します。CPUが継続的に張り付き、メモリ圧迫やディスク待ちが見られないなら、チップ性能が候補です。メモリ圧迫やスワップが発生しているなら、メモリ容量の検討が先になります。
新しいリモートMacでは依存関係を固定する
リモートMacやCI/CD環境の初回ビルドでは、リポジトリの取得、Swift Packageの解決、パッケージのダウンロードが加わります。これはソースコードのコンパイルとは別の待ち時間です。Swift Packageを使う場合は、Package.resolvedをコミットし、実行環境で意図した解決結果が使われているか確認します。
git clone "<REPOSITORY_URL>" "<PROJECT_PATH>"
cd "<PROJECT_PATH>"
xcodebuild \
-resolvePackageDependencies \
-workspace "<WORKSPACE_PATH>" \
-scheme "<SCHEME_NAME>"
プライベートパッケージでは、認証情報、SSH鍵、アクセス許可、取得経路を個別に確認します。AppleのSwift PackageをCI/CDで扱う公式資料に沿って、解決結果を追跡可能にします。
保存してよいキャッシュと、毎回再生成すべき成果物も分けます。古いキャッシュで偶然通った状態を性能改善と判断すると、別のMacやCI/CDで再現できません。
テストは並列度と実行内容を分けて比較する
テスト全体の時間を、そのままXcode 26のコンパイル時間と見なしてはいけません。アプリのビルド、シミュレーター起動、テスト実行、UI操作、失敗後の再実行には別の要因があります。Appleのシミュレーターまたは実機でアプリを実行する資料を参照し、実行先も記録します。
並列テストは、常に総時間を短くするとは限りません。シミュレーターの同時起動でCPUやメモリが競合すれば、個々のテストが遅くなり、失敗や再試行で全体が長引くことがあります。低い並列度から段階的に比較し、短時間のフィードバック用とリリース前の完全実行用を分けます。
テスト構成の整理方法は、Appleのフィードバック改善に向けたテスト編成ガイドと整合させます。
リモートMacへ切り替える前の判定表
リモートMacは、プロジェクトの無駄を直す代わりにはなりません。一方で、Archiveやテストを常時実行し、ローカルMacを開発作業に戻したい場合には、構築作業を分離する選択肢になります。
| 計測で見えた状態 | 先に行うこと | リモートMacの判断 |
|---|---|---|
| SwiftファイルやTargetの再構築が多い | 依存関係とコードを修正 | 構成変更後に再計測 |
| Package取得が長い | Package.resolved、認証、取得経路を確認 | 環境を固定して再評価 |
| CPU負荷が継続して高い | 並列度とビルド範囲を確認 | 上位チップを候補にする |
| メモリ圧迫が続く | シミュレーター数と常駐処理を削減 | メモリ容量を優先して比較 |
| Archiveやテストだけが重い | タスクを分割して自動化 | 常駐ビルド環境を検討 |
利用候補を確認する際は、SFTPMACのMac環境一覧と、Macレンタル料金の比較情報を別々に確認します。価格や構成だけでなく、必要な作業が安定して完了するかを基準にします。
構築環境の加速を受け入れる前の確認
- [ ] 同じコミット、Scheme、構成、実行先で初回ビルドを記録した
- [ ] 増分ビルドで不要なTargetやスクリプトが動いていない
- [ ] Build Timing Summaryの長時間タスクを分類した
- [ ] DerivedDataの削除を定型手順にしていない
- [ ] Package.resolvedとプライベート依存関係の認証を確認した
- [ ] Debug、Release Archive、テストを別々に計測した
- [ ] CPU、メモリ圧迫、ディスク待ち、依存関係取得を切り分けた
- [ ] 同一プロジェクトをリモートMacで再実行し、複数回の安定性を確認した
プロジェクト側の問題が残ったまま構成を上げても、無駄な再コンパイルや依存関係取得は残ります。逆にハードウェア不足が明確なら、ローカル作業と常駐Archiveを分けることで、開発用Macの占有を避けられます。
よくある判断をFAQで確認する
Xcode 26で各コンパイルタスクの時間を確認する方法
Xcodeのレポートナビゲーターでビルド記録を開き、Build Timing Summaryを確認します。コマンドラインではxcodebuildに-showBuildTimingSummaryを付けると、コンパイル、リンク、スクリプトなどの処理時間を分けて確認できます。同じコミットとSchemeで記録することが前提です。
DerivedDataを消しても継続的に速くならない理由
DerivedDataの削除は、壊れた中間生成物やキャッシュ不整合の切り分けには有効です。ただし削除直後は中間生成物を再作成するため、増分ビルドの利点を失います。毎回の高速化手順にはせず、キャッシュ異常が確認できた場合に限定するのが安全です。
リモートMacではチップとメモリのどちらを増やすべきか
CPU使用率が高い状態でコンパイルが進み続けるなら、チップ性能を比較します。メモリ圧迫、スワップ、複数シミュレーターの同時起動が見えるなら、メモリ容量を優先します。依存関係の取得やスクリプトが原因なら、ハードウェア変更は後回しです。
Swift Packageの再解析を止めるための確認点
Package.resolvedをリポジトリに含め、毎回同じ解決結果が使われているかを確認します。リモートMacやCI/CDでは、依存関係の解決、パッケージのダウンロード、ソースのコンパイルを別々に記録します。プライベート依存関係では認証とアクセス許可も確認が必要です。
Xcodeの並列テストを増やすと必ず速くなるか
並列度を上げるほど速くなるとは限りません。シミュレーター、CPU、メモリの競合で失敗や再実行が増える場合があります。低い並列度から段階的に比較し、短時間のフィードバック用テストと、リリース前に全件を実行するテストを分けて運用します。
現在の環境とリモートMacを比較して決める
現在のMacを使い続ける場合、ローカル作業中にArchiveやテストでCPU・メモリを占有しやすく、ストレージ不足や依存関係の再取得も開発時間に影響します。さらに、夜間や別メンバーの作業中に常駐ビルドを動かしにくい点も、小規模チームでは見落とされがちです。
計測後もCPU、メモリ、ディスク待ちがボトルネックとして残るなら、同じプロジェクトで増分ビルド、クリーンArchive、テストをリモートMacで確認する価値があります。SFTPMACのMacレンタルは、購入前の構成検証や、一定期間だけ必要なiOSビルド環境を用意したい場合に向いています。
反対に、長期的な高負荷処理、物理ポートへの接続、常時手元での操作が必要なら、自前のMacが適しています。Xcode 26のコンパイルが遅すぎるという症状だけで契約や買い替えを決めず、計測結果がハードウェア不足を示した場合に、SFTPMACの利用環境を同一プロジェクトで検証するのが安全です。