Как работает Compilation Cache в Xcode 26

Разработчики под iOS хорошо знают: чем серьезнее проект, тем дольше он собирается. Добавил пару строк - жди. Запустил сборку на CI - опять жди. В Xcode 26 появился механизм, который пытается разорвать этот порочный круг - Compilation Cache.

В чем проблема:

Каждый день в команде происходит одно и то же. Несколько разработчиков работают в параллельных ветках. CI-сервер пересобирает каждый пул-реквест с нуля. Одни и те же зависимости и внутренние модули компилируются снова и снова. Большая часть этой работы - лишняя.

DerivedData не всегда решал эту задачу. Он был временным хранилищем, которое при проблемах советуют просто удалить. Это удобно для локальной отладки, но не дает никаких гарантий для переиспользования сборок.

Что предлагает Compilation Cache:

Начиная с Xcode 26, результаты компиляции можно сохранять в кэш осмысленно и с возможностью переиспользования. Ключевое изменение: Xcode теперь сам решает, можно ли переиспользовать результат компиляции, основываясь на том, что именно изменилось. Если исходные файлы, настройки компилятора или тулчейн не поменялись - работа не повторяется, а результат берется из кэша.

Особенно заметно это при переключении между ветками и при чистых сборках, когда кэш уже прогрет.

Как включить:

Достаточно добавить в настройки сборки:


После этого кэш будет накапливаться по мере компиляции.

Где разница будет заметна:

• Переключение веток. Если ветки затрагивают разные части проекта, кэш помогает избежать перекомпиляции модулей, которые не менялись.


• Чистые сборки. Раньше clean build означал полную перекомпиляцию. Теперь, если кэш сохранен на диске, можно переиспользовать уже собранные артефакты.


• CI с высоким потоком пул-реквестов. Если настроить сохранение кэша между запусками, повторная работа сокращается значительно.

Почему не всем станет сильно быстрее:

Компиляция - не единственная стадия сборки. Обработка ассетов, копирование файлов, скриптовые фазы (линтеры, генерация кода), линковка и встраивание - все это может оставаться узким местом. Если сборка тормозит из-за них, кэш компиляции не поможет.

Swift Packages и модульность:

Логика подсказывает, что модульность помогает кэшированию. На практике эффект зависит от того, как система сборки моделирует граф зависимостей. Возможна ситуация, когда проект на Xcode-таргетах получает хороший прирост, а проект с большим количеством Swift-пакетов - меньший. Это не повод отказываться от SwiftPM, а лишь текущее состояние еще не до конца отлаженной фичи.

Как понять, что кэш работает:

Самый простой способ - собрать проект один раз (чтобы прогреть кэш), затем собрать еще раз без изменений и сравнить время. Если время не упало, открыть отчет сборки и посмотреть, какие этапы занимают больше всего времени. Скорее всего, это окажутся скрипты, обработка ассетов или копирование ресурсов.

Вывод:

Compilation Cache - одно из самых практичных улучшений производительности в Xcode за последнее время. Он не исправит все медленные сборки и не заменит хорошую организацию проекта, но он решает конкретную и очень дорогую проблему - повторную компиляцию того, что уже было скомпилировано.