Hapus DerivedData Xcode & Cache Pengembang dengan Aman
AskClean Team · Updated 2026-07-18
DerivedData adalah folder kerja Xcode untuk hasil build dan indeks, dan ia bisa diam-diam membengkak hingga puluhan gigabyte. Menghapusnya aman: tutup Xcode, buang isi ~/Library/Developer/Xcode/DerivedData, dan Xcode membangun semuanya kembali pada build berikutnya. Panduan ini membahas itu, plus simulator, arsip, dan cache paket.
Apa itu DerivedData dan mengapa ia membengkak
DerivedData adalah tempat Xcode menyimpan segala yang ia turunkan dari kode sumber Anda: objek build antara, produk hasil kompilasi, cache modul, indeks simbol untuk pelengkapan kode dan lompat-ke-definisi, serta log build. Lokasinya secara bawaan di ~/Library/Developer/Xcode/DerivedData, dengan satu subfolder per proyek atau workspace yang pernah Anda buka.
Ia tumbuh karena alasan struktural: Xcode membuat folder DerivedData untuk setiap proyek yang Anda buka — termasuk klona sekali-pakai yang Anda build sekali lalu tak pernah disentuh lagi — dan tak pernah menghapus satu pun. Tiap folder menampung hasil build terpisah per konfigurasi dan tujuan (Debug dan Release, simulator dan perangkat), jadi satu proyek berukuran sedang saja bisa memakan beberapa gigabyte, dan folder ini secara keseluruhan lazim mencapai 20-50 GB di mesin pengembang aktif.
Semua isinya bisa dibuat ulang menurut definisinya sendiri — itulah arti "derived". Menghapus DerivedData tak pernah menyentuh kode sumber, pengaturan proyek, maupun apa pun yang berada di bawah kontrol versi. Satu-satunya ongkos adalah waktu: build berikutnya untuk tiap proyek adalah clean build penuh, dan pengindeksan berjalan lagi di latar belakang selama beberapa menit.
Hapus DerivedData
Ada tiga cara melakukannya, dan hasil akhirnya sama. Perintah Clean Build Folder di Xcode (Product > Clean Build Folder, atau Command-Shift-K) hanya membersihkan hasil build proyek yang sedang terbuka — berguna untuk memperbaiki build yang aneh, tetapi nyaris tak menggerakkan jarum ruang disk. Untuk mendapatkan ruang yang sesungguhnya, hapus folder-folder DerivedData itu sendiri.
Menghapus per proyek adalah opsi bedahnya: pertahankan DerivedData untuk dua-tiga proyek yang Anda build tiap hari, dan buang folder milik yang lainnya. Menghapus seluruhnya adalah opsi cepat, dan itu juga tak masalah — Anda hanya membayar ongkos build-ulang penuh untuk semua proyek sekaligus.
- Tutup Xcode lebih dulu. Menghapus DerivedData saat Xcode berjalan bisa membuat pengindeksnya kebingungan, dan berkas yang sedang dibuka Xcode mungkin tak terhapus bersih.
- Temukan foldernya: di Xcode, buka Settings > Locations, lalu klik panah kecil di sebelah jalur DerivedData untuk menampilkannya di Finder. Atau di Finder tekan Command-Shift-G dan masukkan ~/Library/Developer/Xcode/DerivedData langsung.
- Urutkan subfolder proyek berdasarkan ukuran, pilih yang ingin Anda singkirkan (atau Command-A untuk semuanya), lalu pindahkan ke Sampah. Ke Sampah dulu adalah kebiasaan yang lebih aman — Anda bisa memulihkannya seketika bila berubah pikiran.
- Lewat Terminal sebagai gantinya: rm -rf ~/Library/Developer/Xcode/DerivedData menghapus semuanya sekali jalan. Ini lebih cepat daripada Finder untuk folder yang sangat besar, tetapi baca catatan di bawah sebelum memakainya.
- Buka kembali Xcode dan lakukan build. Bersiaplah build pertama tiap proyek berjalan jauh lebih lama, dan "Indexing" tampil di bar aktivitas untuk beberapa saat — keduanya ongkos sekali bayar.
Hati-hati dengan rm -rf: ia melewati Sampah dan menghapus permanen, tanpa bisa dibatalkan. Ketik jalurnya persis, jangan pernah menjalankannya dengan sudo untuk tugas ini, dan bila Anda tak nyaman di Terminal, jalur Finder mengerjakan hal yang sama secara terpulihkan.
Bersihkan runtime simulator lama
Simulator biasanya pemakan ruang pengembang terbesar kedua setelah DerivedData. Setiap runtime iOS, watchOS, atau tvOS yang pernah Anda unduh memakan 5-8 GB, dan tiap perangkat simulasi menyimpan folder datanya sendiri di bawah ~/Library/Developer/CoreSimulator/Devices. Bila Anda sudah melewati beberapa kali peningkatan Xcode, kemungkinan besar Anda punya runtime untuk versi iOS yang berhenti Anda targetkan bertahun-tahun lalu.
Kemenangan tercepat adalah perintah pembersihan bawaan: jalankan xcrun simctl delete unavailable di Terminal. Ia menghapus setiap perangkat simulator yang runtime-nya sudah tak terpasang — yatim piatu peninggalan versi Xcode lama — dan tak menyentuh apa pun yang masih bisa Anda pakai.
Untuk runtime-nya sendiri, buka Settings > Platforms di Xcode (disebut Components pada versi Xcode lebih lama). Anda akan melihat tiap runtime simulator terpasang beserta ukurannya; pilih yang lama lalu hapus. Simpan hanya runtime terbaru per platform kecuali Anda memang aktif menguji di versi OS lama.
Anda juga bisa memangkas perangkat simulasi satu per satu di Window > Devices and Simulators: pindah ke tab Simulators, klik kanan perangkat yang tak pernah Anda pakai — enam model iPhone duplikat berisi data uji lama itu — lalu pilih Delete. Data dan aplikasi tersimpan tiap perangkat ikut terhapus.
Arsip, berkas device support, dan cache
Arsip menumpuk di ~/Library/Developer/Xcode/Archives setiap kali Anda menjalankan Product > Archive untuk mendistribusikan build. Tiap arsip berisi build aplikasi lengkap plus simbol debug dSYM-nya, sering 100 MB hingga 1 GB per arsip. Sebelum menghapus, pahami kompromnya: dSYM di dalamnyalah yang memungkinkan Anda men-simbolikasi laporan crash untuk build persis itu. Simpan arsip untuk versi yang masih hidup di App Store atau TestFlight (atau pastikan App Store Connect sudah memiliki dSYM-nya), dan hapus sisanya — rute teraman adalah Organizer di Xcode (Window > Organizer > Archives), tempat Anda bisa meninjau dan menghapusnya dengan konteks.
iOS DeviceSupport, di ~/Library/Developer/Xcode/iOS DeviceSupport, menampung simbol debug yang disalin Xcode dari setiap iPhone atau iPad fisik yang pernah Anda colokkan — satu folder per versi iOS, umumnya 2-5 GB per folder. Folder untuk versi iOS yang sudah tak dijalankan satu pun perangkat Anda adalah beban mati murni: hapus saja, dan bila kelak Anda menyambungkan lagi perangkat pada versi itu, Xcode tinggal menyalin ulang simbolnya (Anda akan melihat "Preparing debugger support" sekali). Folder saudaranya juga ada untuk perangkat watchOS dan tvOS.
Xcode juga menyimpan cache-nya sendiri di ~/Library/Caches/com.apple.dt.Xcode, dan simulator menyimpan miliknya di ~/Library/Developer/CoreSimulator/Caches — keduanya aman dibersihkan saat Xcode dan aplikasi Simulator tak sedang berjalan, dan keduanya dibangun ulang sesuai kebutuhan.
Cache manajer paket (SwiftPM, CocoaPods, npm, Homebrew)
Manajer paket menyimpan setiap dependensi yang pernah diunduh agar pemasangan berikutnya cepat. Itu rekayasa yang bagus sekaligus higiene disk yang buruk: cache-nya hanya bisa tumbuh, dan di mesin yang sudah melewati beberapa tahun proyek, diam-diam totalnya mencapai 10-20 GB. Semuanya aman dibersihkan — skenario terburuknya, pemasangan berikutnya mengunduh ulang paket.
Swift Package Manager menyimpan cache paket unduhannya di ~/Library/Caches/org.swift.swiftpm, dan checkout terselesaikan tiap proyek juga berada di dalam folder DerivedData-nya — jadi membersihkan DerivedData sudah sekaligus membersihkan itu. Cache bersamanya bisa Anda hapus dari Finder, atau dengan rm -rf pada jalur tersebut.
CocoaPods menyimpan pod unduhannya di ~/Library/Caches/CocoaPods. Cara bersih mengosongkannya adalah perintah bawaan: pod cache clean --all. Folder Pods proyek-proyek Anda tak tersentuh; hanya cache unduhan yang hilang.
Cache npm berada di ~/.npm dan bisa mencapai banyak gigabyte di mesin yang sarat JavaScript. Jalankan npm cache clean --force untuk mengosongkannya (npm mewajibkan flag itu karena cache-nya memulihkan diri sendiri dan normalnya tak pernah perlu dibersihkan — menghapusnya tetap sepenuhnya aman). Pengguna pnpm bisa menjalankan pnpm store prune sebagai gantinya.
Homebrew menimbun unduhan lama dan versi paket yang usang. brew cleanup menghapus versi usang dan unduhan basi; brew cleanup --prune=all juga mengosongkan seluruh cache unduhan. Jalankan brew cleanup -n lebih dulu bila Anda ingin daftar uji-coba tentang apa saja yang akan hilang.
Otomatiskan saja
Semua langkah di atas berhasil, tetapi sampah pengembang itu seperti treadmill: DerivedData kembali dalam seminggu kerja normal, cache terisi lagi, dan setiap pembaruan Xcode menelantarkan satu runtime lagi. Bila Anda enggan mengulang enam prosedur manual setiap bulan, inilah bagian yang layak diotomatiskan — dengan alat yang memperlihatkan penalarannya alih-alih menghapus massal diam-diam.
AskClean memperlakukan berkas pengembang sebagai kategori kelas satu: sekali pindai merinci Xcode DerivedData per proyek, runtime simulator lama (dibaca lewat simctl, dengan menyimpan yang terbaru per platform), berkas device support, dan cache manajer paket untuk npm, SwiftPM, cargo, uv, dan lainnya. Ia juga menangkap pemakan ruang generasi baru — cache model Hugging Face dan Ollama — yang dirinci per model dan dibiarkan tak dicentang secara bawaan.
Setiap item hadir dengan penjelasan — benda apa itu, bisakah dibangun ulang, apa ongkos menghapusnya — dan tak ada yang berjalan sampai Anda mengonfirmasinya. Penghapusan masuk ke Sampah sehingga klik yang keliru cukup diseret balik untuk dibatalkan, dan kode sumber, dokumen, serta foto Anda tak pernah tersentuh. Isinya sama dengan daftar periksa panduan ini, minus satu jam kerja di Terminal.
FAQ
Apakah aman menghapus DerivedData?
Ya — ini salah satu penghapusan besar teraman 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 berada di tempat lain dan tak pernah terpengaruh. Satu-satunya konsekuensi adalah build berikutnya tiap proyek berupa build ulang penuh dan pengindeksan berjalan lagi.
Seberapa sering saya harus membersihkan DerivedData?
Tak ada jadwal wajib — bersihkan saat ukurannya sudah cukup berarti, yang bagi kebanyakan pengembang aktif berarti tiap satu-dua bulan. Dua momen selalu membenarkannya: saat Anda butuh ruang disk cepat, dan saat sebuah proyek menunjukkan galat build yang tak bisa dijelaskan atau pelengkapan kode yang basi, di mana menghapus DerivedData adalah perbaikan pertama yang standar.
Apakah Xcode jadi lebih lambat setelah saya menghapus DerivedData?
Sementara, ya. Build pertama tiap proyek adalah clean build, yang bisa memakan waktu berkali lipat dibanding build inkremental, dan pengindeksan latar belakang butuh beberapa menit sebelum pelengkapan kode dan pencarian pulih sepenuhnya. Setelah siklus pertama itu, performa kembali persis seperti semula — DerivedData menampung cache, bukan optimisasi yang hilang permanen.
Bagaimana dengan ~/Library/Developer/CoreSimulator — boleh saya hapus?
Jangan membabi buta — ia menampung simulator yang sedang terpasang beserta datanya, dan menghapusnya bulat-bulat merusak semuanya sampai Anda memasang ulang runtime. Pangkas dengan benar: jalankan xcrun simctl delete unavailable untuk perangkat yatim, buang runtime lama di Settings > Platforms milik Xcode, hapus perangkat tak terpakai di Devices and Simulators, dan bersihkan manual hanya subfolder Caches-nya.
Apakah Clean Build Folder melakukan hal yang sama?
Tidak. Product > Clean Build Folder (Command-Shift-K) hanya membersihkan hasil build proyek yang sedang terbuka, dan membiarkan indeks, cache modul, serta folder semua proyek lain tetap ada. Ia alat penelusuran masalah build, bukan alat ruang disk — mendapatkan ruang yang sesungguhnya berarti menghapus folder-folder DerivedData itu sendiri.
Sources