Стоит ли включать Tuist Xcode Cache? Решение для удалённого Mac в 2026

По записи Tuist от 8 сентября 2026 года, механизм повторного использования частей кэша был изменён для сокращения лишней передачи данных, но это не является обещанием одинакового ускорения для каждого проекта — официальное описание изменения. Поэтому решение принимается не по самому факту включения Tuist Xcode Cache, а по источнику задержки.

Повторная компиляция занимает большую часть времени → сначала проведите ограниченный тест Tuist Xcode Cache.
Очередь к Mac, UI-тесты или подпись доминируют → расширьте или разделите пул удалённых Mac; если проявляются обе причины, применяйте кэш и масштабирование параллельно.

Эта статья предназначена для разработчиков крупных iOS/macOS-проектов, которым нужно уменьшить повторную компиляцию одинаковых зависимостей и исходников. Она также полезна DevOps-инженерам, поддерживающим самоуправляемый Mac CI, и руководителям платформ, принимающим решение об оптимизации, аренде или закупке узлов.

Последнее обновление: 15 сентября 2026 года. Факты о поведении Tuist Cache, передаче фрагментов, настройках CI и маршрутизации Runner сверены с официальными материалами Tuist, Apple и GitHub, приведёнными в статье.

SECTION 01Сначала отделите компиляцию от всего остального

Время «сборки» в интерфейсе CI редко является одной технической величиной. Для принятия решения вам нужны отдельные интервалы:

• ожидание задания до назначения Runner;
• подготовка рабочего каталога и получение исходников;
• разрешение зависимостей;
• компиляция Swift, Objective-C и модулей;
• выполнение скриптов;
• передача кэшированных артефактов;
• запуск тестов и Simulator;
• архивирование и кодовая подпись;
• доставка результата.

Apple рекомендует использовать данные о времени сборки и разбирать инкрементальную компиляцию по этапам, а не оценивать проект по общей длительности job — это описано в документации Apple по ускорению инкрементальных сборок Xcode.

Практический пример: job длится 18 минут, но Runner назначается только через 7 минут, компиляция занимает 6 минут, UI-тесты — ещё 4 минуты, а архивирование и публикация — оставшиеся минуты. В таком случае кэш может сократить только часть шестиминутного участка. Он не создаст свободный Runner, не ускорит ожидание графической сессии и не отменит требования к подписи.

Начните с Xcode Build Timing Summary и журнала CI. Для одного и того же коммита сохраните:

• время постановки задания;
• время назначения узла;
• длительность компиляционных задач;
• состояние локального или удалённого кэша;
• время загрузки и скачивания;
• длительность тестов;
• время архивации и подписи.

Если вы не можете получить эти значения раздельно, включать кэш «на глаз» преждевременно. Сначала исправьте наблюдаемость: иначе после изменения пайплайна вы не поймёте, какая часть улучшилась.

SECTION 02Когда Tuist Xcode Cache является разумным первым экспериментом

Tuist Xcode Cache имеет смысл, когда проект часто выполняет сопоставимую компиляцию, а окружение достаточно стабильно для повторного использования результата. В официальном руководстве Tuist по Xcode Cache описаны общая модель, требования к среде CI, отправка артефактов и состояния попадания в кэш.

Перед запуском проверьте четыре условия:

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

Кэш особенно логичен для pull request-сборок, где множество заданий последовательно затрагивает общие модули. Однако изменение публичного интерфейса, флагов компилятора, версии SDK или исходных файлов может законно привести к промаху. Это не обязательно означает неисправность Tuist Cache: кэш обязан считать изменившийся вход новым результатом.

Признаки, что проект ещё не готов к кэшированию

Отложите эксперимент, если:

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

В такой ситуации первый шаг — не увеличение кэша, а фиксация входов и единый способ запуска. Иначе низкая доля попаданий будет следствием разъехавшихся условий, а не ограничением технологии.

SECTION 03Почему кэш может попадать, но пайплайн всё равно оставаться медленным

Наличие статуса cache hit ещё не означает, что job стала быстрее. Нужно смотреть, где именно произошёл hit и сколько времени заняла подготовка результата. Разделите как минимум три состояния:

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

Затем сопоставьте каждое состояние с размером результата и сетевым маршрутом. В обновлении Tuist от 8 сентября 2026 года описано повторное использование частей передаваемых данных; это уменьшает лишнюю работу при обмене, но не превращает медленный или удалённый endpoint в локальное хранилище. Поэтому нельзя переносить частный результат изменения на все проекты.

Проверьте:

• где находится endpoint кэша относительно Runner;
• сколько времени занимает установление соединения;
• есть ли отдельные этапы upload и download;
• какие артефакты передаются полностью, а какие переиспользуются частично;
• не загружается ли результат, который затем не используется;
• совпадают ли архитектура, SDK, параметры и путь окружения.

Решение удобно принимать по наблюдаемому результату. Если удалённый hit стабильно короче полной компиляции вместе с передачей, кэш оставляйте. Если передача съедает выигрыш, ограничьте загрузку, измените политику публикации или разместите endpoint ближе к пулу. Если проблема появляется только на части веток из-за различий входов, не увеличивайте кэш вслепую — сначала исправьте воспроизводимость.

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

SECTION 04Очередь удалённых Mac и компиляция требуют разных решений

Самоуправляемый Runner не начинает задание только потому, что оно находится в очереди. GitHub описывает требования к меткам, доступности и маршрутизации self-hosted Runner в официальной документации по Runner. Если подходящий Mac занят, отключён, не имеет нужной метки или не соответствует архитектуре, кэш не позволит этому же узлу принять вторую задачу одновременно.

Отделяйте две ситуации:

• медленный запуск: задание долго ждёт подходящий узел;
• медленное выполнение: задание уже запущено, но компиляция, тесты или архивирование занимают много времени.

Если очередь растёт только в рабочие часы, проверьте конфликт PR-сборок с плановыми задачами. Если релизная архивация блокирует обычные проверки, разделите маршрутизацию по назначению. Если задания требуют разных SDK, архитектур или секретов, одна общая группа Runner создаёт ложное ощущение нехватки мощности.

Аренда удалённого Mac может быть оправдана как способ быстро добавить совместимый узел для отдельной очереди, но это не отменяет проверки меток, архитектуры, доступа к репозиторию и секретам. В описании MACNOX можно отдельно изучить вариант доступа к реальному удалённому Mac; техническое решение всё равно следует принимать по вашим журналам CI, а не по обещанию универсального ускорения.

SECTION 05UI-тесты, Simulator и подпись не являются обычной компиляцией

Tuist Cache может помочь подготовить скомпилированные компоненты, но UI-тест выполняется в Simulator или на физическом устройстве. Apple отдельно описывает этот процесс и требования к запуску приложения в документации о Simulator и физических устройствах. Если задержка возникает при загрузке runtime, старте графической сессии, установке приложения или выполнении сценариев, увеличение кэша не решит источник проблемы.

Для архивации добавляются другие ограничения: конфигурация signing, сертификаты, provisioning profile, связка ключей и доступ к секретам. Техническая заметка Apple об устранении проблем архивации показывает, почему успешная компиляция ещё не означает успешный выпуск.

Схема с отдельными пулами обычно рациональнее единого большого пула:

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

Это не универсальное требование. Если ваши тесты короткие, не используют графику и не конкурируют с release-задачами, разделение может добавить операционную сложность без пользы. Но если один тип job постоянно блокирует другой, изоляция становится способом устранить конфликт, а не попыткой «ускорить Mac».

SECTION 06Пошаговый тест для выбора кэша, расширения или двухконтурной схемы

Проведите эксперимент на одном и том же коммите. Не сравнивайте одновременно разные версии Xcode, разные архитектуры и разные наборы тестов.

1. Зафиксируйте версию Xcode, SDK, архитектуру, схему, параметры CI и набор задач. Запишите, какие секреты и профили используются, но не помещайте их значения в журнал.

2. Запустите холодную сборку без опоры на предыдущий локальный результат. Сохраните время ожидания Runner, разрешения зависимостей, компиляции, скриптов, тестов, архивации и публикации.

3. Повторите тот же сценарий с включённым Tuist Xcode Cache. Убедитесь, что CI-аутентификация и политика загрузки действительно активны, а состояние cache hit или miss попало в лог.

4. Сравните локальное и удалённое попадание. Отдельно измерьте скачивание, распаковку или подготовку результата. Не складывайте это время с компиляцией в одну неопределённую метрику.

5. Повторите запуск на занятом пуле и на пуле с доступным Runner. Если разница между началом job и назначением узла велика, перед вами проблема очереди, а не компиляции.

6. Выполните UI-тесты и архивирование в том же сравнении. Зафиксируйте, какой участок не изменился после попадания в кэш, и проверьте требования Simulator, сертификатов и ключевой связки.

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

8. Проверьте откат. Пайплайн должен уметь выполнить обычную компиляцию без кэша, а release-задачи — запускаться в отдельном маршруте, если кэш-сервис или общий Runner недоступны.

Чек-лист перед окончательным решением

• [ ] В журнале раздельно видны очередь, компиляция, передача кэша, тесты и подпись.
• [ ] Сравнивается один коммит с одинаковыми параметрами Xcode и SDK.
• [ ] Различаются локальное попадание, удалённое попадание и промах.
• [ ] Проверены архитектура, флаги, пути окружения и генерируемые файлы.
• [ ] Проверена аутентификация CI, а не только ручной доступ разработчика.
• [ ] UI-тесты и Simulator измеряются отдельно от компиляции.
• [ ] Архивирование и кодовая подпись измеряются отдельно от тестового пула.
• [ ] Для очереди записаны метки Runner, состояние узлов и фактическое время назначения.
• [ ] Есть маршрут обычной сборки при отключённом кэше.
• [ ] Для добавления Mac определены причина, очередь и тип задач, которые он должен принимать.

SECTION 07Финальное решение по трём сценариям

Если повторная компиляция является главным расходом времени, оставьте текущий пул и сначала испытайте Tuist Xcode Cache. Если попадания нестабильны, не скрывайте проблему средними значениями: найдите различающиеся входы, исправьте их или ограничьте область применения.

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

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

Если после такой проверки ваш текущий вариант — локальный Windows/Linux-компьютер, виртуальная macOS или один перегруженный Mac mini, у него есть конкретные недостатки: нельзя гарантировать подходящую macOS-среду для всех задач, очередь одного узла блокирует независимые пайплайны, а Simulator и подпись конкурируют с обычными сборками. Для временного расширения пула разумнее взять в аренду реальный удалённый Mac через условия MACNOX, выделив его под PR, тесты или выпуск. Это не обязательно лучший вариант для постоянной тяжёлой нагрузки или задач, которым нужны физические интерфейсы, но для проверки гипотезы, сезонного роста очереди и изолированного Mac CI такой путь позволяет сначала измерить результат, а уже затем решать вопрос о собственной инфраструктуре.