Hapus DerivedData Xcode & Cache Pengembang dengan Aman
Tim AskClean · Diperbarui 2026-11-02
DerivedData adalah folder kerja Xcode untuk hasil build dan indeks, dan ukurannya bisa diam-diam membengkak hingga puluhan gigabyte. Folder ini aman dihapus: keluar dari Xcode, hapus isi ~/Library/Developer/Xcode/DerivedData, dan Xcode akan membuat ulang semuanya pada build berikutnya. Panduan ini membahas langkah tersebut, ditambah simulator, Archives, dan cache paket.
Apa itu DerivedData dan mengapa ukurannya membengkak
DerivedData adalah tempat Xcode menyimpan semua yang dihasilkannya dari kode sumber Anda: objek build perantara, produk hasil kompilasi, cache modul, indeks simbol untuk pelengkapan kode dan jump-to-definition, serta log build. Secara bawaan, lokasinya di ~/Library/Developer/Xcode/DerivedData, dengan satu subfolder untuk setiap proyek atau workspace yang pernah Anda buka.
Ukurannya membengkak karena alasan struktural: Xcode membuat folder DerivedData untuk setiap proyek yang Anda buka — termasuk klon sekali pakai yang hanya di-build sekali lalu tak pernah disentuh lagi — dan tidak menghapusnya secara proaktif. Setiap folder menyimpan hasil build terpisah per konfigurasi dan tujuan (Debug dan Release, simulator dan perangkat), jadi ukurlah subfolder proyeknya alih-alih menebak berapa ruang yang akan kembali di Mac Anda.
Menurut definisinya, semua isi folder ini dapat dibuat ulang — itulah arti “derived” (turunan). Menghapus DerivedData tidak pernah menyentuh kode sumber, pengaturan proyek, atau apa pun yang berada di bawah kontrol versi. Satu-satunya biayanya adalah waktu: build berikutnya untuk setiap proyek menjadi clean build penuh, dan pengindeksan berjalan lagi di latar belakang selama beberapa menit.
Hapus DerivedData
Perintah Clean Build Folder di Xcode (Product > Clean Build Folder, atau Shift-Command-K) hanya membersihkan hasil build proyek yang sedang terbuka — berguna untuk memperbaiki build yang bermasalah, tetapi nyaris tidak menambah ruang disk. Untuk mendapatkan kembali ruang yang berarti, hapus folder DerivedData itu sendiri: tampilkan lewat pengaturan Locations di Xcode, buka langsung foldernya di Finder, atau hapus lewat Terminal. Ketiga cara itu berujung pada hasil yang sama.
Menghapus per proyek adalah cara yang paling terarah: pertahankan DerivedData untuk dua atau tiga proyek yang Anda build setiap hari, lalu hapus folder milik proyek lainnya. Menghapus semuanya adalah cara tercepat, dan itu juga tidak masalah — Anda hanya menanggung biaya build ulang penuh untuk semua proyek sekaligus.
- Keluar dari Xcode terlebih dahulu. Menghapus DerivedData saat Xcode masih berjalan dapat mengacaukan pengindeksnya, dan berkas yang sedang dibuka Xcode mungkin tidak terhapus dengan bersih.
- Temukan foldernya: di Xcode, buka Settings > Locations, lalu klik panah kecil di samping jalur DerivedData untuk menampilkannya di Finder. Atau, di Finder tekan Command-Shift-G dan masukkan langsung ~/Library/Developer/Xcode/DerivedData.
- Urutkan subfolder proyek menurut ukuran, pilih yang ingin dihapus (atau tekan Command-A untuk memilih semuanya), lalu pindahkan ke Tong Sampah. Memindahkan ke Tong Sampah lebih dulu adalah kebiasaan yang lebih aman — Anda bisa langsung memulihkannya jika berubah pikiran.
- Atau lewat Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData menghapus semuanya sekaligus. Cara ini lebih cepat daripada Finder untuk folder yang sangat besar, tetapi baca catatan di bawah sebelum memakainya.
- Buka kembali Xcode dan jalankan build. Build pertama setiap proyek akan memakan waktu jauh lebih lama, dan “Indexing” akan tampil di bilah aktivitas untuk sementara — keduanya hanya terjadi sekali.
Hati-hati dengan rm -rf: perintah ini melewati Tong Sampah dan menghapus secara permanen, tanpa bisa dibatalkan. Ketik jalurnya dengan tepat, jangan pernah menjalankannya dengan sudo untuk tugas ini, dan jika Anda belum terbiasa dengan Terminal, cara lewat Finder memberi hasil yang sama dan masih bisa dipulihkan.
Bersihkan runtime simulator lama
Simulator juga sering menjadi salah satu kategori penyimpanan pengembang yang besar. Setiap runtime iOS, watchOS, atau tvOS yang diunduh memakan ruang tersendiri, dan setiap perangkat simulasi menyimpan data di ~/Library/Developer/CoreSimulator/Devices. Jika Xcode Anda sudah beberapa kali diperbarui, periksa runtime untuk versi OS yang tidak lagi termasuk dalam pengujian Anda.
Langkah tercepat adalah perintah pembersihan bawaan: jalankan xcrun simctl delete unavailable di Terminal. Perintah ini menghapus setiap perangkat simulator yang berstatus unavailable — kebanyakan sisa dari runtime yang sudah dihapus dan versi Xcode lama — beserta aplikasi dan data di dalamnya. Tinjau dulu daftarnya dengan xcrun simctl list devices, terutama jika Anda memasang lebih dari satu versi Xcode.
Untuk runtime-nya sendiri, buka Settings > Components di Xcode (bernama Platforms di Xcode 14–15). Di sana tercantum setiap runtime simulator yang terpasang beserta ukurannya; pilih runtime lama lalu hapus. Simpan hanya runtime terbaru untuk setiap platform, kecuali Anda masih aktif menguji di versi OS yang lebih lama.
Anda juga bisa menghapus perangkat simulasi satu per satu di Window > Devices and Simulators: buka tab Simulators, klik kanan perangkat yang tidak pernah Anda pakai — misalnya enam model iPhone kembar berisi data dari pengujian lama — lalu pilih Delete. Aplikasi dan data yang tersimpan di perangkat itu ikut terhapus.
Archives, berkas DeviceSupport, dan cache
Arsip menumpuk di ~/Library/Developer/Xcode/Archives setiap kali Anda menjalankan Product > Archive untuk mendistribusikan build. Setiap arsip berisi build aplikasi lengkap beserta simbol debug dSYM-nya, sering kali 100 MB hingga 1 GB per arsip. Sebelum menghapus, pahami konsekuensinya: dSYM di dalam arsip itulah yang memungkinkan Anda melakukan simbolikasi laporan crash untuk build yang persis sama. Simpan arsip untuk versi yang masih tersedia di App Store atau TestFlight (atau pastikan App Store Connect sudah memiliki dSYM-nya), lalu hapus sisanya — cara teraman adalah lewat Organizer di Xcode (Window > Organizer > Archives), tempat Anda dapat meninjau dan menghapusnya dengan konteks yang jelas.
iOS DeviceSupport, di ~/Library/Developer/Xcode/iOS DeviceSupport, berisi simbol debug yang disalin Xcode dari setiap iPhone atau iPad fisik yang pernah Anda sambungkan — satu folder per versi iOS, umumnya 2–5 GB per folder. Folder untuk versi iOS yang tidak lagi dijalankan oleh perangkat Anda mana pun hanya membuang ruang: hapus saja, dan jika kelak Anda menyambungkan lagi perangkat dengan versi itu, Xcode cukup menyalin ulang simbolnya (Anda akan melihat “Preparing debugger support” satu kali). Folder serupa juga ada untuk perangkat watchOS dan tvOS.
Xcode juga menyimpan cache-nya sendiri di ~/Library/Caches/com.apple.dt.Xcode, dan simulator menyimpan cache-nya di ~/Library/Developer/CoreSimulator/Caches. Keduanya dibuat ulang sesuai kebutuhan, tetapi bersihkan hanya saat Xcode dan aplikasi Simulator sudah ditutup, dan biarkan berkas cache CoreSimulator yang tidak Anda kenali.
Cache manajer paket (SwiftPM, CocoaPods, npm, Homebrew)
Manajer paket menyimpan dependensi yang sudah diunduh agar pemasangan berikutnya cepat. Itu berguna, tetapi di Mac yang sudah bertahun-tahun dipakai untuk banyak proyek, cache ini tetap bisa menjadi kategori yang besar. Cache unduhan ini dapat dibuat ulang, tetapi pemasangan berikutnya harus mengunduh paket lagi.
Swift Package Manager menyimpan cache paket yang diunduh di ~/Library/Caches/org.swift.swiftpm, dan checkout dependensi yang sudah di-resolve untuk setiap proyek juga berada di dalam folder DerivedData proyek itu — jadi membersihkan DerivedData sekaligus membersihkan checkout tersebut. Cache bersamanya dapat Anda hapus lewat Finder, atau dengan rm -rf pada jalur tersebut.
CocoaPods menyimpan pod yang diunduh di ~/Library/Caches/CocoaPods. Cara yang rapi untuk mengosongkannya adalah perintah bawaannya: pod cache clean --all. Folder Pods di proyek Anda tidak tersentuh; hanya cache unduhan yang dihapus.
Cache npm berada di ~/.npm dan bisa membengkak hingga beberapa gigabyte di Mac yang sering dipakai untuk proyek JavaScript. Jalankan npm cache clean --force untuk mengosongkannya (npm mewajibkan flag itu karena cache-nya dapat memperbaiki diri sendiri dan biasanya tidak perlu dibersihkan; menghapusnya tetap aman — paket cukup diunduh lagi pada pemasangan berikutnya). Pengguna pnpm dapat menjalankan pnpm store prune sebagai gantinya.
Homebrew menimbun unduhan lama dan versi paket yang sudah usang. brew cleanup menghapus versi usang dan unduhan lama; jika dijalankan tanpa nama paket, perintah ini juga mencopot dependensi yang tidak lagi dibutuhkan apa pun (kecuali HOMEBREW_NO_AUTOREMOVE ditetapkan). brew cleanup --prune=all juga mengosongkan seluruh cache unduhan. Jalankan brew cleanup -n lebih dulu jika Anda ingin melihat daftar uji coba (dry run) tentang apa saja yang akan dihapus.
Otomatiskan prosesnya
Semua langkah di atas berfungsi, tetapi membersihkan sampah pengembang itu seperti berlari di atas treadmill: DerivedData kembali menumpuk setelah seminggu kerja normal, cache terisi lagi, dan setiap pembaruan Xcode meninggalkan satu runtime lagi. Jika Anda tidak ingin mengulang enam prosedur manual setiap bulan, bagian inilah yang layak diotomatiskan — dengan alat yang menunjukkan alasannya, bukan menghapus massal secara diam-diam.
AskClean memperlakukan berkas pengembang sebagai kategori tersendiri: satu kali pemindaian merinci DerivedData Xcode per proyek, runtime simulator lama (dibaca lewat simctl, dengan tetap menyimpan yang terbaru untuk setiap platform), berkas DeviceSupport, serta cache manajer paket untuk npm, SwiftPM, cargo, uv, dan lainnya. AskClean juga menemukan pemakan ruang yang lebih baru — model AI lokal — dengan mencantumkan model Hugging Face satu per satu dan pustaka model Ollama sebagai satu item, semuanya tidak dicentang secara bawaan.
Setiap item disertai penjelasan — apa itu, apakah dapat dibuat ulang, dan apa konsekuensi menghapusnya — dan tidak ada yang dijalankan sampai Anda mengonfirmasinya. Item yang dikonfirmasi dihapus secara permanen, tidak dipindahkan ke Tong Sampah, jadi tinjau setiap pilihan sebelum mengonfirmasi; kode sumber dan perpustakaan foto Anda tidak pernah disentuh. Isinya sama dengan daftar periksa di panduan ini, tanpa harus bekerja satu jam di Terminal.
Mana yang dapat dibuat ulang—dan mana yang tidak
Ini tabel batas penghapusan, bukan klaim penghematan yang berlaku untuk semua Mac. Ukur Mac Anda sebelum dan sesudah setiap tindakan — skrip audit hanya-baca di panduan penyimpanan Simulator Xcode melaporkan folder-folder ini tanpa mengubah apa pun.
| Kategori | Lokasi bawaan | Konsekuensi penghapusan |
|---|---|---|
| DerivedData | ~/Library/Developer/Xcode/DerivedData | Di-build dan diindeks ulang; kode sumber dan riwayat Git tetap utuh. |
| Perangkat simulator | ~/Library/Developer/CoreSimulator/Devices | Aplikasi dan data uji di perangkat virtual yang dipilih hilang; hapus lewat simctl atau Xcode. |
| Archives | ~/Library/Developer/Xcode/Archives | Bisa ikut menghapus dSYM yang diperlukan untuk simbolikasi crash; tinjau dulu di Organizer. |
| DeviceSupport | ~/Library/Developer/Xcode/iOS DeviceSupport | Simbol debug disalin lagi saat perangkat dengan versi OS itu disambungkan kembali. |
FAQ
Apakah aman menghapus DerivedData?
Ya — ini salah satu penghapusan berukuran besar yang paling aman di Mac. DerivedData hanya berisi berkas yang dihasilkan Xcode dari kode sumber Anda: hasil build, cache modul, indeks, dan log. Kode, berkas proyek, dan riwayat Git Anda tersimpan di tempat lain dan tidak pernah terpengaruh. Satu-satunya konsekuensinya: build berikutnya untuk setiap proyek menjadi build ulang penuh, dan pengindeksan berjalan lagi.
Seberapa sering saya perlu membersihkan DerivedData?
Tidak ada jadwal wajib — bersihkan saat ukurannya sudah cukup berarti, yang bagi kebanyakan pengembang aktif berarti sebulan atau dua bulan sekali. Ada dua saat yang selalu tepat: ketika Anda butuh ruang disk dengan cepat, dan ketika sebuah proyek menampilkan galat build yang tidak bisa dijelaskan atau pelengkapan kode yang usang — dalam kasus itu, menghapus DerivedData adalah perbaikan pertama yang lazim.
Apakah Xcode jadi lebih lambat setelah DerivedData dihapus?
Untuk sementara, ya. Build pertama setiap proyek adalah clean build, yang bisa berlangsung beberapa kali lebih lama daripada build inkremental, dan pengindeksan di latar belakang butuh beberapa menit sebelum pelengkapan kode dan pencarian pulih sepenuhnya. Setelah siklus pertama itu, performanya kembali seperti semula — DerivedData berisi cache, bukan optimisasi yang hilang secara permanen.
Bagaimana dengan ~/Library/Developer/CoreSimulator — bolehkah saya menghapusnya?
Jangan sembarangan — folder ini berisi simulator yang sedang terpasang beserta datanya, dan menghapusnya sekaligus akan merusak simulator tersebut sampai Anda memasang ulang runtime. Rapikan dengan cara yang benar: jalankan xcrun simctl delete unavailable untuk perangkat yang berstatus unavailable (aplikasi dan datanya ikut terhapus), hapus runtime lama di Settings > Components di Xcode, hapus perangkat yang tidak dipakai di Devices and Simulators, dan bersihkan secara manual hanya subfolder Caches, dengan Xcode dan Simulator dalam keadaan tertutup.
Apakah Clean Build Folder melakukan hal yang sama?
Tidak. Product > Clean Build Folder (Shift-Command-K) hanya membersihkan hasil build proyek yang sedang terbuka, dan membiarkan indeks, cache modul, serta folder semua proyek lain tetap ada. Perintah ini adalah alat untuk mengatasi masalah build, bukan untuk mengosongkan ruang disk — untuk mendapatkan kembali ruang yang berarti, hapus folder DerivedData itu sendiri.
Sumber