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), когда симптомы связаны не с продуктами сборки: Xcode показывает ошибки в уже исправленном коде, переход к определению ведёт не туда, автодополнение перестало понимать ваши собственные типы. Это симптомы индекса, а Clean Build Folder индекс не трогает. Отдельный случай — кэш предкомпилированных модулей 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 до и после.

Частые вопросы