Xcode の Archives は削除できる？古いビルドを安全に消す方法

Archives が DerivedData と違う理由

Product > Archive を実行するたびに、Xcode は配布用のビルドを .xcarchive バンドルとして保存します。既定の保存場所は ~/Library/Developer/Xcode/Archives で、日付ごとのフォルダに分けられ、Organizer にも表示されます。長く運用しているアプリでは、リリース候補、TestFlight へのアップロード、正式版が何世代も積み上がります。

DerivedData と違い、アーカイブは単なる高速化のためのキャッシュではありません。そのビルドで実際に生成されたアプリのバイナリ、ビルドのメタデータ、dSYM ファイルが含まれる場合があります。Apple の説明どおり、dSYM は UUID によって特定のバイナリと結び付いています。同じソースを後から再ビルドしても、新しいバイナリには別の識別子が付くため、元のシンボルファイルの代わりにはなりません。

この違いが整理のルールを変えます。DerivedData は、最初のビルドが遅くなるだけで作り直せます。一方、削除したアーカイブは、まったく同じ形では作り直せないことがあります。そのバイナリのクラッシュレポートが届いたときに対応するシンボルがなければ、スタックフレームはメモリアドレスのままで、関数名やソース上の位置に戻せません。

削除する前に「残すもの」を決める

Finder ではなく Xcode から始めます。Window > Organizer を開いて Archives を選び、対象のアプリを選んで、各項目のバージョン、ビルド番号、作成日、配布状況を確認します。Organizer なら、日付だけのフォルダ名からは分からない情報を見ながら判断できます。

削除リストより先に、残すリストを作ります。現在ユーザーに提供しているすべてのバージョン、稼働中のすべての TestFlight ビルド、まだインストールされている Enterprise / Ad Hoc ビルド、今後もクラッシュレポートを調査する可能性のあるリリースのアーカイブは残してください。書き出したバイナリ、公証の記録、署名の証跡をチームが頼りにしているなら、問題なく動いたリリースも 1 つ残しておきます。

アップロードに成功したからといって、ローカルのアーカイブが不要になるとは限りません。プラットフォームやアップロード設定によっては Apple にシンボルが送られていますが、Apple のデバッグに関する資料は、配布したすべてのビルドについてアーカイブを保持するよう勧めています。ローカルのアーカイブは、バイナリ、dSYM、バージョン、ビルド番号、書き出し結果を結び付ける、もっとも明確な記録でもあります。

1. Window > Organizer を開き、Archives を選択します。
2. アプリを選び、現在使われている正式版、TestFlight、Enterprise、Ad Hoc ビルドのバージョンとビルド番号をすべて記録します。
3. 必要なシンボルが該当する場所にアップロードされていることを確認し、保持規程で求められている場合は、代わりのないアーカイブをバックアップされるストレージへコピーします。
4. 置き換え済みのリリース候補、放棄した社内ビルド、クラッシュ調査の対象期間を過ぎた旧バージョンだけを削除候補にします。
5. Organizer から候補を一つずつ削除し、必要な項目が残っていることを確かめてからゴミ箱を空にします。

日付だけを基準にした保持ルールは安全ではありません。新しいバージョンを公開した後も、古い正式版のバイナリがユーザーの端末に長く残ることがあります。

削除せずにサイズを測る

目的が容量なら、まず測ります。Finder で Command + Shift + G を押し、~/Library/Developer/Xcode/Archives を開きます。リスト表示に切り替え、表示オプションで「すべてのサイズを計算」をオンにして、サイズ順に並べます。読み取りだけの操作なので何も変わらず、特に大きなアーカイブが一目で分かります。

ターミナルなら du -sh ~/Library/Developer/Xcode/Archives で合計を確認できます。日付フォルダごとに調べるには du -sh ~/Library/Developer/Xcode/Archives/* を実行し、結果を自分で並べ替えます。どちらもサイズを測るだけで、何も削除しません。

.xcarchive はパッケージなので、Finder では通常 1 つの項目として表示されます。サイズの原因を調べるときは、コピーしたアーカイブを右クリックして「パッケージの内容を表示」を選んでも構いませんが、元のバンドルの中のファイルは編集しないでください。中のファイルを一部だけ削除すると、見た目は残っていても、書き出しやシンボリケートが正しくできないアーカイブになります。

もっとも安全な削除手順

削除には Organizer を使うのが第一の選択肢です。アプリ、バージョン、ビルド番号を見ながら操作できるからです。配信終了を確認したアーカイブを選択して Delete を使うと、Xcode がアーカイブのバンドルを削除します。macOS や Xcode の動作によっては、確認を求められることがあります。

Organizer で古いバンドルや破損したバンドルを開けない場合は、Finder を使います。Archives フォルダを開き、Info.plist のメタデータを監査の記録と照合して対象の .xcarchive を特定し、そのバンドルだけをゴミ箱に移します。名前の日付が古いという理由だけで、日付フォルダを丸ごと削除しないでください。

Organizer を開き直して確認し、ワークフローに必要なビルドを書き出し、シンボルが業務上重要なら代表的なクラッシュを実際にシンボリケートできることを確かめるまで、ゴミ箱は空にしないでください。ゴミ箱に入れておけば、短いながらも復元の猶予ができます。ターミナルで完全に削除しても整理が正確になるわけではなく、その安全の余地がなくなるだけです。

増え続けない保持ポリシーを作る

保持の基準は、単純な経過日数ではなく配布の状態に置きます。現在配布中のビルドはすべて残し、置き換え済みの正式版は、クラッシュレポートを受け付けている期間は残します。Enterprise ビルドはインストールの有効期限が切れるまで残し、法務・サポート・インシデント対応の規程で必要な節目のリリースは規程どおりに保持します。

チームでは、保持ルールをリリースのチェックリストに明記します。アーカイブの保存場所、dSYM をアップロードしたかどうか、誰が取り出せるか、いつ削除できるようになるかを記録してください。外付けやクラウドのストレージに移す場合は、コピーがあるだけで安心せず、実際に復元して使えるかを試します。

大きなリリースサイクルの後に、フォルダを見直しましょう。四半期ごとに 10 分の棚卸しをするほうが、起動ディスクがいっぱいになってから慌てて消すより安全です。すぐに低リスクで容量を空けたいなら、まず DerivedData と不要になったシミュレータのデータを整理し、Mac に余裕ができてから落ち着いて Archives を見直してください。

AskClean が Archives を扱う方法

AskClean は、Xcode Archives を通常の作り直せるキャッシュとして扱わないよう設計されています。Archives フォルダをスキャンして .xcarchive バンドルを一つずつ一覧にし、元に戻せないコストがあることを警告するので、フォルダ全体を消すか残すかの二択にならずに古いビルドを確認できます。

最終的な判断はユーザーに委ねられます。AskClean は、どのアーカイブが容量を使っているかを示し、承認した項目を完全に削除できますが、製品のサポート期間を知ることも、失われた dSYM を作り直すこともできません。この線引きは意図的なものです。ストレージの自動化は、リリースの成果物を見えるようにするためのもので、もう不要だと黙って決めるためのものではありません。

削除の境界：作り直せるもの、作り直せないもの

経過日数やサイズで判断する前に、復旧のコストで分類します。

よくある質問