クラッシュシンボルを失わずに古い Xcode Archives を削除する

Archives が DerivedData と違う理由

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

DerivedData はソースから作り直せる一時データですが、Archive には、そのリリースで実際に生成されたバイナリ、メタデータ、dSYM が含まれる場合があります。Apple の説明どおり、dSYM は UUID で特定のバイナリと結び付いています。同じコミットを再ビルドしても、元のシンボルの代わりにはなりません。

つまり削除コストが違います。DerivedData なら次回のビルドとインデックスが遅くなるだけです。Archive を誤って削除すると、そのビルドのクラッシュスタックを関数名やソース位置へ戻せなくなる可能性があります。

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

Finder の日付だけで判断せず、Window > Organizer から Archives を開いてください。アプリを選び、各項目のバージョン、ビルド番号、作成日、配布状況を確認します。この文脈があれば、古そうに見えるフォルダ名だけで判断するより安全です。

現在 App Store で提供中のバージョン、稼働中の TestFlight ビルド、まだ利用されている Enterprise / Ad Hoc ビルド、クラッシュ調査期間内の旧正式版は保持します。再エクスポート、署名確認、インシデント対応で使う基準ビルドも残してください。

アップロード成功だけを理由にローカル Archive を捨てないでください。設定によって Apple にシンボルが送られている場合はありますが、Apple のデバッグ資料も配布した各ビルドのアーカイブ保持を勧めています。ローカル Archive は、バイナリ、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 上では一つのパッケージです。調査用のコピーに「パッケージの内容を表示」を使うのは構いませんが、正式な Archive の内部ファイルを部分的に削除しないでください。見た目は残っていても、エクスポートやシンボリケートができない壊れたアーカイブになります。

もっとも安全な削除手順

第一選択は Organizer です。アプリ、バージョン、ビルド番号を見ながら、引退を確認した Archive だけを Delete できます。Finder で日付フォルダを推測するより、対象を取り違えにくくなります。

Organizer が古い、または破損したバンドルを読めない場合だけ Finder を使います。Info.plist の情報を監査記録と照合し、該当する .xcarchive 一つだけをゴミ箱へ移してください。日付が古いという理由でフォルダ全体を消さないでください。

すぐにゴミ箱を空にせず、Organizer を開き直し、必要なビルドが残っていることを確認します。シンボルが重要なら代表的なクラッシュレポートも検証してください。完全削除に急いでも、判断の正確さは上がりません。

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

保持期間は単純な経過日数ではなく、配布状態で決めます。現在配信中のビルドはすべて保持し、旧正式版はクラッシュを受け付ける期間まで、Enterprise ビルドは導入先で失効するまで残します。法務・監査・重大インシデント用の節目ビルドは規程に従います。

リリース手順に、Archive の保存場所、dSYM のアップロード状況、取得権限、削除可能になる条件を記載してください。外付けやクラウドへ移す場合は、コピーが見えるだけで安心せず、復元とエクスポートを実際に試します。

大きなリリースサイクルごとに短時間の棚卸しを行えば、起動ディスクが満杯のときに慌てて消さずに済みます。緊急時は DerivedData など再生成可能なデータを先に片づけ、Archives は落ち着いて監査してください。

AskClean が Archives を扱う方法

AskClean は Xcode Archives を通常の再生成可能キャッシュとして扱いません。.xcarchive を個別に一覧化し、不可逆なコストを警告するため、フォルダ全体を一括で消す必要がありません。

最終判断は利用者が行います。AskClean はサイズを示し、承認された項目をゴミ箱へ移せますが、製品のサポート期間を決めたり、失われた dSYM を作り直したりはできません。自動化はリリース成果物を見せるところまでで、その価値を勝手に決めません。

削除境界：再生成できるもの、できないもの

古さや大きさより先に、復元コストで分類します。

よくある質問