Xcode: Clean Build Folder чи видалення DerivedData?

Різниця — в охопленні, а не в ретельності

Product > Clean Build Folder (Shift-Command-K) працює в межах відкритого проєкту й схеми. Команда викидає скомпільовані продукти й проміжні файли для цього контексту, тож наступна збірка починається з вихідного коду. Вона стосується одного проєкту й навмисно зберігає те, що дорого відтворювати.

DerivedData — спільний каталог верхнього рівня для всіх проєктів, що використовують типове розташування: ~/Library/Developer/Xcode/DerivedData, по підпапці на кожен проєкт чи workspace, який ви колись відкривали. Видалення однієї підпапки скидає саме цей проєкт. Видалення всього каталогу змушує кожен ваш проєкт перезібратися й переіндексуватися під час наступного відкриття.

Тож чесно описувати цю пару як «легке» і «глибоке» очищення не варто. Clean Build Folder — вузький і дешевий інструмент, а видалення DerivedData — широкий, і ціна йому — індекс. Що з них доречне, залежить лише від того, де саме зламалося: усередині продуктів збірки чи поза ними.

Коли ламається збірка, починайте з вузького

Якщо помилка зʼявилася одразу після перемикання гілки, зміни конфігурації збірки чи редагування файлів ресурсів, зупиніть запущену програму і спершу виконайте Clean Build Folder. Це найдешевше скидання: індекс зберігається, і ви повертаєтеся до роботи за одну збірку, а не за збірку плюс кілька хвилин індексування.

Переходьте до видалення папки DerivedData цього проєкту, коли симптоми насправді не стосуються продуктів збірки: Xcode показує помилки в коді, який ви вже виправили, перехід до визначення веде не туди, автодоповнення перестало розуміти ваші власні типи. Це симптоми індексу, а Clean Build Folder індексу не торкається.

Є один окремий випадок, який варто знати, бо саме через нього «очистив — не допомогло» зазвичай перетворюється на «видалив DerivedData — допомогло»: кеш попередньо скомпільованих модулів (ModuleCache.noindex) лежить у корені DerivedData, а не в підпапці якогось проєкту. Clean Build Folder до нього не дістає. Коли кеш модулів застаріває після зміни SDK чи інструментарію, помилку усуває лише його видалення.

Жодна з команд не виправить справжньої помилки у вашому коді чи залежностях. Якщо та сама помилка лишається після чистої збірки, припиніть очищення й прочитайте повідомлення компілятора: причина — в налаштуваннях проєкту, Package.resolved, вибраному SDK або в самому коді.

Жоден із варіантів не є способом звільнити диск

Clean Build Folder — діагностичний інструмент, який заодно звільняє трохи байтів. Він може повернути місце для поточного проєкту, але продукти збірки інших проєктів, усі індекси й кеш модулів лишаються там, де були. Запускати його заради місця на диску — означає міряти не те.

Якщо мета справді місце, дійте навпаки: спершу виміряйте підпапки DerivedData, а потім видаліть проєкти, які ви не відкривали місяцями. Саме там зазвичай і лежать десятки гігабайтів — разові клони, які ви зібрали один раз і до яких не поверталися.

Не починайте з rm -rf. Finder дає змогу перемістити вибрані папки в Смітник, звідки їх можна повернути, доки ви його не очистили, — і ця різниця стане важливою, щойно ви вперше видалите папку проєкту, який саме зараз збирається. «Термінал» доречний для автоматизації, але лише після того, як ви перевірили точний шлях.

Перевіряйте результат, а не довіряйте цифрам

Перш ніж щось робити, запишіть розмір DerivedData, застосуйте лише один із двох варіантів і виміряйте знову. Після Clean Build Folder зберіть поточну схему. Після видалення папки DerivedData відкрийте Xcode й дочекайтеся завершення першої збірки та індексування.

Такий порядок відокремлює звільнене місце від ціни, яку ви за нього заплатили. Універсальної цифри немає: результат залежить від того, скільки проєктів, конфігурацій і архітектур збиралося на цьому конкретному Mac.

Що вибрати

Таблиця описує охоплення, а не обіцяну кількість гігабайтів. Виміряйте свій Mac до й після.

Часті запитання