Xcode フルビルド比較：ローカル MacBook とクラウド M4 専用ノード

フルビルドが増分ビルドよりマシン上限を示す理由

日常開発では、Xcode の増分ビルドがハードウェア差を隠してしまう。ファイルを 1 つ変え、数個の target だけ再コンパイルすれば、 8 GB の MacBook Air も 16 GB の Pro も「使える」ように見える。 しかし main へのマージ、CI による Clean Build、ローカルでの xcodebuild clean build による Release 検証では、 コンパイラがすべての Swift モジュールを同時に起動し、フル型チェックと全 Extension のリンクを行う—— ここがメモリ、放熱、CPU 持続負荷の本番だ。

個人開発者からよく聞くのは「ビルドの途中でファンが暴走し、Simulator が固まり、Slack も切り替えられない」という声。 原因は Xcode のバージョンではなく、フルビルドがマシンを持続高負荷に追い込むことにある。 ノート PC の放熱とユニファイドメモリはモバイル用途向けで、5〜10 分の連続コンパイル向けではない。 本比較は「同一プロジェクト・同一コマンド・異なるマシン」の実時間差に焦点を当て、 ローカルハードをアップグレードするか、重いコンパイルをクラウド専用ノードへ移すかの判断材料を提供する。

統一テスト手法：「バラバラにビルド」しない

コンパイル速度の比較で最も多いミスは、マシンごとに状態が違うこと—— Chrome のタブ 40 個を開いた機、再起動直後の機、先週の DerivedData が残った機。 以下のベースラインを固定し、数値の横並び比較を可能にした：

1. 01
   同一 Git commit

   3 台とも git checkout v2.4.0-buildbench。依存バージョンと Package.resolved を固定し、SPM 解決時間のノイズを排除。

2. 02
   コマンドラインビルド、GUI は閉じる

   Xcode の Product → Build は使わず、xcodebuild と /usr/bin/time -l で実時間とピークメモリを取得。

3. 03
   「現実的なデスクトップ」背景負荷を再現

   ローカル MacBook は Slack、Chrome（8 タブ）を追加実行。Simulator は起動せず。クラウド M4 は SSH セッションとビルドスクリプトのみ——無人 CI 環境を模擬。

4. 04
   2 種類のビルドをそれぞれ計測

   Debug clean build（開発検証）と Release archive（リリース経路）。所要時間と swap ページ数を個別に記録。

Debug ビルドの例： xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Debug clean build -destination 'generic/platform=iOS' -jobs 10。 計測はコマンド実行から ** BUILD SUCCEEDED ** 出力まで。pod install と証明書インポートは含まない。

Clean Build の実時間：M4 と 2 世代の MacBook

Debug フルビルドの中央値は以下のとおり。クラウド M4 はローカル M1 Pro より約 15% 速く、 M2 Air より 2 倍以上速い——差の主因は、Air が 3 分目あたりでメモリ圧縮と swap を発動し、 過熱により CPU クロックが 3.4 GHz 付近から約 2.6 GHz まで落ちることにある。

Release Archive では Debug より差が広がる。最適化レベルが高く、リンク段階がメモリをより消費する。 M2 Air は Archive 時に swap ピーク 4.1 GB、実時間は 9 分近く。 同一プロジェクトを M4 で走らせると 16 GB 物理メモリを超えず、ビルド曲線は平坦で「後半だけ急に遅くなる」拐点がない。 リリースフローで週 1 回以上フル Archive があるなら、この差は待ち時間コストとノート PC の実用性コストに直結する。

増分ビルド：日常の体感とフルビルド結論がずれる理由

開発体験を補完するため、「Swift ファイル 1 つ変更後の増分ビルド」も計測した—— IDE で Cmd+B する最も多いパスだ。3 台の差は大幅に縮小：クラウド M4 17 秒、M1 Pro 22 秒、M2 Air 38 秒（Chrome は起動したまま）。 増分は影響モジュールだけ再コンパイルし、ピークメモリは 5 GB 未満。M2 Air でも swap は発生しない。

つまり、時間の 90% を小さな反復開発に使うなら、ローカルの 8 GB Air で十分ということ。 痛みが出るのはリリース週、大規模依存アップデート、ブランチ切り替え後の初回フルビルドだ。 多くのチームは「日常コーディングはローカル、フルビルドは CI」—— しかし GitHub ホスト Runner だとピーク時に待ちだけで 20 分以上かかることもあり、コンパイル本体より長い。 ローカル Air と変わらない体感になる。フルビルド専用のクラウド M4 1 台を固定するのは、「ローカルで我慢」と「公共キューで待つ」の中間の第三の選択肢だ。

発熱・ファンと「ビルド中に別作業できるか」

コンパイルはストップウォッチの問題だけではない。並行ワークフローにも影響する。フルビルド中に筐体温度とファン回転数を記録した（M4 mini は外付け温度センサー、ノートは内蔵センサー）：

ファンレスの M2 Air は持続コンパイルでチップ保護のため能動的にクロックダウンする—— 最初の 2 分は M1 Pro に近い速度だが、残り 3 分はどんどん遅くなる。7 分の合計時間の「見えない原因」はここにある。 クラウド Mac mini はデスクトップ向け放熱で、M4 の 10 性能コアを長時間高クロックで維持できる。 実務的には、SSH セッションでフルビルドをバックグラウンド実行し、ローカルの Windows や Linux メイン機でコーディング・会議・資料閲覧を続けられる——リソースを奪い合わない。

16 GB ユニファイドメモリ：足りるラインと足りないライン

今回プロジェクトの Debug フルビルドのピークは約 12.4 GB——16 GB マシンの快適圏内だ。 20 万行超の巨大化、または Xcode + Simulator + Instruments の同時起動では、 16 GB ローカル機も限界に触れる——同一 M1 Pro で iOS 17 Simulator の UI テストを重ねると、 15.6 GB まで上がり 800 MB の swap が発生。フルコンパイルは 4m 18s から 5m 44s に伸びた。

M2 Air の 8 GB はコンパイル開始 90 秒でメモリ上限に到達し、OS が積極的に圧縮とページングを開始。 memory_pressure ログに vm_compressor イベントが大量に出現し、 コンパイルスレッドがメモリ解放を待つため、実時間はほぼ 2 倍に伸びる。 これは Xcode の「最適化不足」ではなく物理メモリのハードリミット—— クラウド M4 の 16 GB は、多くの中規模 iOS プロジェクトにとって「swap しない最低ライン」であり、過剰スペックではない。

実測の再現：スクリプトと計測上の注意

以下の最小スクリプトをローカルとクラウドノードでそれぞれ実行し、結果を CSV に記録して比較できる。 プロジェクトルートに scripts/bench_clean_build.sh として保存：

#!/bin/bash
set -euo pipefail
SCHEME="MyApp"
WORKSPACE="MyApp.xcworkspace"
rm -rf ~/Library/Developer/Xcode/DerivedData/*
/usr/bin/time -l xcodebuild -workspace "$WORKSPACE" -scheme "$SCHEME" -configuration Debug clean build -destination 'generic/platform=iOS' -jobs "$(sysctl -n hw.ncpu)" 2>&1 | tee /tmp/xcode_bench.log
grep -E 'real|maximum resident set size' /tmp/xcode_bench.log

注意：新マシンでは初回ビルド前に xcodebuild -runFirstLaunch を実行。 xcode-select -p が意図した Xcode を指しているか確認。 計測中は Xcode GUI を手動で開かない（SourceKit とインデックスが奪い合う）。 クラウド比較は SSH でスクリプトを実行し、caffeinate -dims でスリープ防止（ローカルノートでも同様）。 VNC は進捗確認のみ——VNC 内で Xcode GUI を開きながら CLI ビルドを計測しない。グラフィカルセッションは追加で 1〜2 GB メモリを消費する。

フルビルドをクラウド M4 に移すタイミング

ローカルを M4 Pro 32 GB に上げるには数千ドルかかる一方、年間のリリースピークは数十日にとどまることも多い。 痛みが「週に 1〜2 回のフル Archive でノートが熱くて膝の上に置けない」のであって、「保存のたびに 30 秒待つ」のでなければ、 日単位でクラウド専用 M4 を借りる方が経済的なことが多い：$21.1/日、$57.1/週、$105.7/月、契約縛りなし、 支払い後 1〜5 分で開設、SSH とブラウザ VNC の両方で接続可能。

PixVPS は 5 リージョン——シンガポール、日本（東京）、韓国（ソウル）、中国香港、米国東部——で同一ハードウェア・同一価格。 日本国内から東京ノードへ SSH でフルビルドしても実時間はローカルとほぼ同じ。発熱と騒音だけデータセンターに残る。 GitHub Actions セルフホスト Runner や Fastlane と組み合わせ可能：ローカルで push、クラウドで xcodebuild archive を実行、 完了後 .ipa を取得するか TestFlight へ直接アップロード（手順は当サイトのクラウド Mac Xcode CI/CD 実践ガイドを参照）。

もう一つの典型：メイン機は Windows、iOS 受託は月に数回——月 1〜2 回のコンパイルのために MacBook を買う必要はない。 リリース週にクラウド M4 を 2 日借り、Xcode と証明書を入れ、終わったら解放。 16 GB ユニファイドメモリ、1 Gbps 専用帯域、99.9% SLA、24/7 有人サポート、チケット 1 時間以内返信。 大規模キャッシュには SSD +1TB（$2.9/日）を追加。夜間の複数 App マトリクスビルドは Thunderbolt 5 並列（$1.9/日から、80 Gbps マルチマシン相互接続）を参照。

フルビルドの比較は「どのチップのベンチマークが高いか」ではなく、5 分以内に安定して仕上げ、並行作業を犠牲にしないかが問いだ。 ローカル MacBook は依然として最高の日常コーディング端末。クラウド M4 専用ノードは「コンパイルのピーク」をノートから切り離す専用コンピュート—— 年に数十日しか使わないピークのために本体を買わず、日単位で支払える。