Xcode: Clean Build Folder atau Hapus DerivedData?

Bedanya ada pada cakupan, bukan ketuntasan

Product > Clean Build Folder (Shift-Command-K) bekerja di dalam proyek dan scheme yang sedang Anda buka. Perintah ini membuang produk hasil kompilasi dan berkas perantara untuk konteks tersebut sehingga build berikutnya dimulai lagi dari kode sumber. Cakupannya hanya satu proyek, dan perintah ini sengaja mempertahankan hal-hal yang mahal untuk dibuat ulang.

DerivedData adalah direktori tingkat atas yang dipakai bersama oleh semua proyek yang menggunakan lokasi bawaan — ~/Library/Developer/Xcode/DerivedData, dengan satu subfolder untuk setiap proyek atau workspace yang pernah Anda buka. Menghapus satu subfolder hanya mengatur ulang proyek itu. Menghapus seluruh direktori membuat semua proyek Anda harus di-build dan diindeks ulang saat dibuka berikutnya.

Jadi, keduanya tidak tepat digambarkan sebagai “pembersihan ringan” versus “pembersihan menyeluruh”. Clean Build Folder bercakupan sempit dan murah; menghapus DerivedData bercakupan luas dan mengorbankan indeks. Mana yang tepat sepenuhnya bergantung pada letak sumber masalahnya: di dalam produk build atau di luarnya.

Saat build gagal, mulailah dari cakupan tersempit

Jika kegagalan muncul tepat setelah Anda berpindah branch, mengubah konfigurasi build, atau menyunting berkas resource, hentikan aplikasi yang sedang berjalan lalu gunakan Clean Build Folder lebih dulu. Inilah cara reset termurah: indeks tetap utuh, dan Anda bisa kembali bekerja setelah satu kali build, bukan satu kali build ditambah beberapa menit pengindeksan.

Naikkan ke langkah berikutnya — menghapus folder DerivedData proyek tersebut — jika gejalanya sebenarnya bukan soal produk build: Xcode menampilkan galat untuk kode yang sudah Anda perbaiki, jump-to-definition mengarah ke tempat yang salah, atau pelengkapan kode tidak lagi mengenali tipe buatan Anda sendiri. Itu gejala masalah indeks, dan Clean Build Folder tidak menyentuh indeks.

Ada satu kasus khusus yang perlu diketahui, karena inilah alasan umum mengapa “sudah di-clean tetapi tidak membantu” berubah menjadi “setelah DerivedData dihapus, berhasil”: cache modul hasil prakompilasi (ModuleCache.noindex) berada di root DerivedData, bukan di dalam subfolder proyek mana pun. Clean Build Folder tidak pernah menjangkaunya. Saat cache modul menjadi usang setelah SDK atau toolchain berubah, hanya menghapusnya yang bisa menghilangkan galat itu.

Tidak satu pun dari keduanya memperbaiki bug sungguhan di kode sumber atau dependensi Anda. Jika galat yang sama tetap muncul setelah clean build, berhentilah membersihkan dan baca pesan compiler — penyebabnya ada di pengaturan proyek, Package.resolved, SDK yang dipilih, atau kode itu sendiri.

Keduanya bukan strategi mengosongkan disk

Clean Build Folder adalah alat diagnosis yang kebetulan membebaskan sedikit ruang. Perintah ini dapat mengembalikan ruang untuk proyek saat ini, tetapi produk build semua proyek lain, semua indeks, dan cache modul tetap berada di tempatnya. Menjalankannya untuk mengosongkan disk berarti mengukur hal yang salah.

Jika tujuan sebenarnya adalah ruang disk, lakukan sebaliknya: ukur dulu subfolder DerivedData, lalu hapus folder proyek yang sudah berbulan-bulan tidak Anda buka. Di sanalah biasanya puluhan gigabyte itu berada — klon sekali pakai yang pernah Anda build satu kali lalu tak pernah dibuka lagi.

Jangan memulai dengan rm -rf. Lewat Finder, Anda bisa memindahkan folder yang dipilih ke Tong Sampah, yang masih bisa dipulihkan sampai Anda mengosongkannya — dan perbedaan itu terasa penting saat pertama kali Anda menghapus folder proyek yang ternyata sedang di-build. Terminal berguna untuk otomatisasi, tetapi hanya setelah Anda memastikan jalurnya dengan tepat.

Periksa hasilnya, jangan sekadar percaya angka

Catat ukuran DerivedData sebelum melakukan apa pun, jalankan hanya salah satu dari dua opsi itu, lalu ukur lagi. Setelah Clean Build Folder, build scheme yang sedang aktif. Setelah menghapus folder DerivedData, buka Xcode dan tunggu sampai build pertama dan proses pengindeksan selesai.

Dengan urutan itu, Anda bisa memisahkan ruang yang berhasil didapat dari harga yang dibayar untuk mendapatkannya. Tidak ada angka universal yang bisa diharapkan: hasilnya bergantung pada berapa banyak proyek, konfigurasi, dan arsitektur yang pernah di-build di Mac tersebut.

Mana yang perlu dipilih

Tabel ini menjelaskan cakupan, bukan janji jumlah gigabyte tertentu. Ukur Mac Anda sendiri sebelum dan sesudahnya.

FAQ