Xcode の Clean Build Folder と DerivedData 削除の違い

違うのは掃除の深さではなく範囲

Product > Clean Build Folder（Shift + Command + K）は、いま開いているプロジェクトとスキームの中だけで動作します。その範囲のコンパイル済みの成果物と中間ファイルを破棄するので、次のビルドはソースからやり直しになります。対象は 1 つのプロジェクトに限られ、作り直すのに時間がかかるものは意図的に残します。

DerivedData は、既定の保存場所を使うすべてのプロジェクトが共有する最上位のディレクトリです。場所は ~/Library/Developer/Xcode/DerivedData で、これまでに開いたプロジェクトやワークスペースごとにサブフォルダが 1 つずつあります。サブフォルダを 1 つ削除すれば、そのプロジェクトだけがリセットされます。ディレクトリ全体を削除すると、手元のすべてのプロジェクトで、次に開いたときに再ビルドとインデックスの再作成が必要になります。

つまり、この 2 つは「軽い掃除」と「徹底的な掃除」の関係ではありません。Clean Build Folder は範囲が狭くコストの小さい操作で、DerivedData の削除は範囲が広く、インデックスを失うコストを伴います。どちらが適切かは、壊れているものがビルド成果物の中にあるのか、外にあるのかによって決まります。

ビルドが壊れたら、狭い範囲から始める

ブランチの切り替え、ビルド構成の変更、リソースファイルの編集の直後から失敗するようになったなら、実行中のアプリを終了し、まず Clean Build Folder を使います。もっともコストの小さいリセットで、インデックスも残るため、「ビルド＋数分間のインデックス作成」ではなく、ビルド 1 回で作業に戻れます。

症状がビルド成果物とは関係なさそうなときは、そのプロジェクトの DerivedData フォルダの削除に進みます。修正済みのコードに Xcode がエラーを表示し続ける、定義へのジャンプが違う場所に飛ぶ、自分で定義した型をコード補完が認識しなくなった、といった症状です。これらはインデックスの症状で、Clean Build Folder はインデックスに触れません。

知っておきたいケースが 1 つあります。「クリーンしても直らなかったのに、DerivedData を削除したら直った」となる典型的な理由です。プリコンパイル済みモジュールのキャッシュ（ModuleCache.noindex）は、プロジェクトのサブフォルダではなく DerivedData の直下にあり、Clean Build Folder はここに届きません。SDK やツールチェーンを変更した後にモジュールキャッシュが古くなった場合、エラーを解消するにはこのキャッシュを削除するしかありません。

どちらのコマンドも、ソースコードや依存関係に実在するバグは直せません。クリーンビルドの後も同じエラーが出るなら、掃除をやめてコンパイラのメッセージを読んでください。原因はプロジェクト設定、Package.resolved、選択している SDK、またはコードそのものにあります。

どちらもディスク容量を空ける方法ではない

Clean Build Folder は診断のためのツールで、容量が少し空くのは副次的な効果にすぎません。現在のプロジェクトの分は空くことがありますが、他のプロジェクトのビルド成果物、すべてのインデックス、モジュールキャッシュはそのまま残ります。容量を取り戻すために実行しても、的外れな対策にしかなりません。

本当の目的が容量なら、逆の順番で進めます。まず DerivedData のサブフォルダのサイズを測り、何か月も開いていないプロジェクトのフォルダを削除します。数十 GB がたまっているのはたいていそこ、つまり一度ビルドしたきり二度と開いていない使い捨てのクローンです。

いきなり rm -rf を使わないでください。Finder なら選んだフォルダをゴミ箱に入れられ、ゴミ箱を空にするまでは元に戻せます。削除したフォルダが、実はいまビルド中のプロジェクトのものだった、という場面で、この違いが効いてきます。ターミナルは自動化には便利ですが、使うのは正確なパスを確認してからにしてください。

数字をうのみにせず、結果を確かめる

作業の前に DerivedData のサイズを記録し、2 つの方法のどちらか一方だけを実行してから、もう一度測ります。Clean Build Folder の後は、現在のスキームをビルドします。DerivedData フォルダを削除した後は、Xcode を開いて最初のビルドとインデックス作成が終わるまで待ちます。

この順番で進めれば、取り戻した容量と、そのために払ったコストを切り分けられます。誰にでも当てはまる目安の数字はありません。結果は、その Mac でビルドしてきたプロジェクト、構成、アーキテクチャの数によって変わります。

どちらを使うべきか

この表は範囲を示すもので、何 GB 空くかを約束するものではありません。作業の前後に、ご自分の Mac で測ってください。

よくある質問