Xcode 27: замедление компиляции — руководство по диагностике удалённого Mac в 2026 году

По состоянию на 24 августа 2026 года официальный список выпусков относит Xcode 27 к версии Beta, поэтому его поведение ещё может измениться между следующими Beta, RC и стабильным выпуском — это подтверждается актуальными заметками к выпускам Xcode. Если после обновления Xcode 27 компиляция стала медленнее, не удаляйте сразу весь DerivedData и не покупайте более мощный узел: сначала отдельно снимите Timing Summary для холодной и инкрементальной сборки, затем проверьте кеширование, зависимости, скрипты, индексацию и фактическую нагрузку удалённого Mac.

Кому пригодится этот материал

Он предназначен для разработчиков iOS и macOS, заметивших изменение времени сборки после обновления Xcode, а также для инженеров DevOps, обслуживающих постоянно работающий узел CI. Руководство особенно полезно, если вам нужно сохранить стабильную производственную цепочку на Xcode 26.6 и параллельно проверить Beta-версию без смешивания результатов.

Последнее обновление: 24 августа 2026 года. Сведения о статусе Xcode 27 проверены по официальным заметкам к выпускам, а команды и методы измерения — по документации о системе сборки и производительности инкрементальных сборок. При выходе новой Beta, RC или стабильной версии диагностику следует повторить.

Сначала зафиксируйте, какая операция действительно замедлилась

Фраза «Xcode 27 компилирует медленно» описывает несколько разных процессов. Холодная сборка после очистки, обычная инкрементальная сборка, Archive, запуск тестов и индексация исходников используют разные части системы. Если сравнить Archive на одном запуске с инкрементальной сборкой на другом, вы получите число, которое нельзя использовать для решения.

В начале диагностики зафиксируйте:

• один и тот же коммит проекта;
• одинаковые Scheme, конфигурацию сборки и целевую платформу;
• одинаковый способ запуска — графический интерфейс Xcode или командная строка;
• состояние зависимостей и пакетного кеша;
• отсутствие параллельных сборок, Preview и тяжёлых задач на узле;
• версию Xcode и выбранный каталог DerivedData.

В Xcode включите отчёт Build With Timing Summary, а для автоматизированной проверки используйте параметр -showBuildTimingSummary у xcodebuild. Описание Apple показывает, как применять временные отчёты для поиска медленных этапов в инкрементальных сборках: официальная методика измерения скорости инкрементальных сборок.

Сохраните исходный журнал, а не только итоговое время. В нём должны быть видны компиляция конкретных целей, подготовка зависимостей, запуск Run Script Phase и другие этапы. Повторите холодную сборку и несколько последовательных инкрементальных сборок. Если задержка есть только при первом запуске, ищите подготовку окружения и зависимости. Если повторно компилируются неизменённые цели, проверяйте граф проекта и входы скриптов.

Так вы получите ответ на первый вопрос: действительно ли Xcode 27 вызвал регрессию, или вы сравниваете разные режимы работы.

Почему каждое изменение кода выглядит как полная сборка

Когда после небольшой правки снова компилируется почти весь проект, наиболее вероятен не «медленный Mac», а потеря условий для инкрементальной сборки. Система должна заново определить зависимости, если изменился входной файл, настройка, сгенерированный артефакт или результат пользовательского скрипта.

Проверьте в Timing Summary и подробном логе:

• повторяется ли компиляция целей, исходники которых не менялись;
• создаётся ли заново файл, от которого зависят многие цели;
• меняется ли конфигурация через условные параметры при каждом запуске;
• совпадает ли каталог DerivedData между ожидаемыми сборками;
• не очищается ли кеш внешним CI-шагом перед каждой задачей;
• не пересоздаётся ли файл конфигурации с новым содержимым или временем изменения.

Документация о системе сборки Xcode и графе зависимостей важнее размера папки DerivedData. Большой каталог не доказывает, что кеш используется правильно, а небольшой каталог не доказывает повреждение. Смотрите, какие входы и цели система считает устаревшими.

Если проект использует явные зависимости модулей, дополнительно сопоставьте предупреждения и порядок подготовки модулей с рекомендациями документации по Explicit Module Dependencies. Не меняйте сразу все настройки проекта: сначала измените одну причину, затем повторите холодную и инкрементальную проверку с тем же коммитом.

Можно ли удалением DerivedData исправить медленную сборку

Удаление DerivedData иногда устраняет повреждённый или несовместимый кеш, но это не универсальный способ ускорить Xcode. После очистки первая сборка почти всегда должна заново подготовить производные файлы, поэтому её результат нельзя принимать за доказательство исправления. Если проблема связана с неверным входом скрипта или повторным разрешением зависимостей, очистка лишь временно скрывает симптом.

Используйте точечное удаление только после сохранения журнала и при наличии признаков повреждения конкретного проекта. В графическом интерфейсе путь можно проверить через настройки Xcode в разделе Locations, а затем удалить каталог только нужного проекта. В CI безопаснее создать новый изолированный рабочий каталог для контрольного запуска, не уничтожая кеши всех остальных задач.

После очистки выполните:

• холодную сборку и сохраните Timing Summary;
• следующую сборку без изменения исходников;
• сборку после небольшой правки одного файла;
• сравнение списка повторно скомпилированных целей;
• проверку, не запускается ли очистка снова в начале CI-задачи.

Если вторая и третья сборки снова выполняют полный объём работы, причина находится в зависимостях, настройках или скриптах, а не в самом факте существования DerivedData.

Зависимости и Run Script Phase как скрытая очередь ожидания

Swift Package, CocoaPods и внутренние генераторы кода могут занимать значительную часть времени до компиляции исходников. На удалённом Mac к этому добавляется сеть: обращение к репозиторию, хранилищу артефактов или серверу лицензирования может ждать ответа, хотя процессор при этом почти не занят.

Сравните первый и последующий запуск по журналу:

Для каждого Run Script Phase укажите точные входные и выходные файлы, если это возможно. Официальное руководство по пользовательским скриптам во время сборки объясняет, почему система не может пропустить скрипт, если не знает, какие результаты считать актуальными.

Вместо безусловного rm -rf и повторной генерации артефактов перенесите логику в условный шаг. Скрипт должен завершаться без работы, когда входы не изменились, а его выход должен существовать по тому пути, который указан в настройках цели. После исправления выполните несколько последовательных инкрементальных сборок: пропуск скрипта должен быть виден в журнале, а не предполагаться по общему времени.

Для пакетных зависимостей полезно разделить сетевую подготовку и собственно сборку. Рекомендации по Swift Package в CI помогают проверить повторное разрешение зависимостей и использование кешей в автоматизированных процессах.

Индексация, Preview и Simulator конкурируют со сборкой

Индексация SourceKit, SwiftUI Preview и Simulator могут заполнять тот же узел, на котором вы запускаете компиляцию. В графическом сеансе это особенно заметно: пользователь видит задержку Xcode, хотя командная сборка без интерфейса завершается предсказуемо. Поэтому нельзя делать вывод о слабой конфигурации удалённого Mac по одному запуску из открытого проекта.

Разделите проверку на два режима:

1. Закройте Preview и Simulator, дождитесь завершения текущей индексации и запустите сборку из командной строки.
2. Повторите тот же запуск в графическом сеансе с включённой индексацией.
3. Сопоставьте Timing Summary, загрузку процессора, давление памяти и активность диска.
4. Проверьте, изменилось ли время компиляции или задержка возникла только до начала компиляции.
5. Убедитесь, что после теста навигация по коду и диагностика исходников продолжают работать.

Постоянное отключение индексации — плохое исправление для рабочей среды: оно убирает один из симптомов, но лишает вас навигации и ранней диагностики ошибок. Сначала изолируйте Preview, параллельный Simulator и лишние фоновые задачи. Если чистая командная сборка нормальна, а интерактивный режим перегружен, меняйте расписание задач или разделяйте рабочую и CI-нагрузку.

Как понять, что проблема в проекте, а не в конфигурации Mac

Оценивать узел следует по наблюдаемым ресурсам во время конкретного этапа, а не по названию чипа или объёму установленной памяти. Для удалённой среды важны свободное место, давление памяти, обмен с диском, активность фоновых процессов и конкуренция между задачами.

Проверьте свободное место на диске и состояние памяти через Activity Monitor. В руководстве по проверке необходимости дополнительной оперативной памяти отдельно рассматриваются Memory Pressure и Swap Used; эти показатели полезнее субъективного ощущения «интерфейс стал тормозить».

Для CI сравните одиночную задачу с параллельным запуском. Если одна сборка стабильна, но несколько задач одновременно вызывают давление памяти или насыщают ввод-вывод, сначала ограничьте конкуренцию и разделите каталоги DerivedData. Общий каталог между несовместимыми версиями Xcode и разными коммитами может создавать гонки и недействительные артефакты.

На удалённом Mac отдельно измерьте сетевую задержку только для этапов, которые действительно обращаются к внешним сервисам. Скорость интерфейса VNC не является показателем скорости компиляции: визуальная сессия может казаться медленной из-за передачи изображения, тогда как xcodebuild выполняет задачу без такой нагрузки.

Пошаговый план проверки перед откатом или расширением

• [ ] Зафиксируйте версию Xcode, коммит, Scheme, конфигурацию, целевую платформу и путь DerivedData.
• [ ] Снимите Timing Summary для холодной сборки, не меняя проект между повторными запусками.
• [ ] Выполните последовательную инкрементальную сборку после небольшой правки и сохраните подробный журнал.
• [ ] Сравните перечень повторно скомпилированных целей, подготовку зависимостей и запуск Run Script Phase.
• [ ] Проверьте, указаны ли входные и выходные файлы у каждого скрипта, который должен пропускаться без изменений.
• [ ] Повторите тест без Preview, Simulator и лишней индексации, затем сравните его с графическим сеансом.
• [ ] Запишите Memory Pressure, Swap Used, свободное место и активность диска во время самого медленного этапа.
• [ ] Сопоставьте одиночную и параллельную сборку на удалённом Mac с раздельными рабочими каталогами.
• [ ] Очистите только подтверждённый повреждённый кеш; не удаляйте весь DerivedData как первый шаг.
• [ ] Если регрессия воспроизводится только в Xcode 27 Beta, оставьте Xcode 26.6 производственным и проведите проверку на изолированном узле.
• [ ] После каждого исправления повторите холодную сборку, последовательные инкрементальные сборки и тест после перезапуска узла.

Решение можно формализовать так: стабильная инкрементальная сборка после исправления скрипта означает, что расширять Mac преждевременно; одинаковая проблема на разных узлах указывает на проект; нормальная одиночная задача и провал только при параллельной нагрузке указывают на конфигурацию или планирование CI.

Когда откатывать Xcode 27, а когда выделять отдельный узел

Если замедление стабильно появляется только на Xcode 27 Beta при том же проекте и тех же входных данных, не переводите производственную цепочку на новую версию до подтверждения причины. Сохраните Xcode 26.6 для релизных задач, а Xcode 27 установите на отдельном удалённом Mac или в ином изолированном рабочем окружении. Так вы сможете сравнить инструменты без смешивания DerivedData, настроек и фоновых процессов.

Если Timing Summary показывает нормальную компиляцию, но узел испытывает длительное давление памяти и активный обмен с диском, расширение конфигурации имеет смысл только после проверки одиночной и параллельной нагрузки. Если же время уходит на повторное разрешение пакетов или безусловные скрипты, более мощный Mac не исправит проект: он лишь сократит часть ожидания и сохранит лишнюю сетевую или файловую работу.

Для отдельной проверки можно арендовать удалённый Mac для тестовой сборочной среды, скопировать тот же коммит, установить обе версии Xcode и повторить зафиксированный сценарий. Такой узел полезен, когда вам нужно сохранить производственный Xcode 26.6 и одновременно проверить Beta без риска изменить основной CI.

Перед решением о долгосрочной эксплуатации проверьте:

• одинаково ли ведут себя холодная и инкрементальная сборки после перезапуска;
• исчезает ли задержка без Preview и параллельных задач;
• повторяется ли проблема на чистом рабочем каталоге;
• сохраняются ли артефакты между последовательными задачами;
• не зависит ли результат от сетевого доступа к пакетам и хранилищу;
• подтверждается ли дефицит ресурсов мониторингом, а не только общим временем.

Если вы постоянно держите два инструментария на одном узле, появляются дополнительные кеши, риск выбора неправильного xcode-select, конкуренция за память и сложность отката. Если вы разделяете версии по узлам, расходы выше, зато результат теста легче воспроизвести и объяснить команде.

Текущая схема на общем Mac или Linux-узле часто имеет три практических недостатка: нельзя надёжно изолировать Beta от производственной среды, параллельные задачи спорят за память и диск, а повторная проверка после перезапуска зависит от состояния чужих кешей и фоновых процессов. В такой ситуации аренда отдельного Mac через KVMFLUX даёт более чистую контрольную среду: вы можете воспроизвести тот же коммит, сохранить root-доступ, разнести версии Xcode и не покупать оборудование ради краткого этапа расследования. Сведения о доступных вариантах можно сверить на странице аренды Mac.

Это не означает, что аренда подходит для любого проекта. Для постоянной тяжёлой нагрузки на длительный срок может быть рациональнее приобрести собственный Mac, а при необходимости физического USB-доступа или локального оборудования удалённый узел не заменит рабочую станцию. Но если задача — временно подтвердить регрессию Xcode 27, провести двойную проверку CI или изолировать стабильную цепочку от Beta, отдельный удалённый Mac обычно даёт более достоверный результат, чем очистка кешей на общем узле.