Xcode Cloud или удалённый Mac CI: выбор в 2026

По данным Apple, участникам Apple Developer Program включено 25 вычислительных часов Xcode Cloud в месяц, а дополнительные планы начинаются со 100 часов. (developer.apple.com)

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

Быстрое решение: стандартные Apple-процессы оставьте в Xcode Cloud, глубоко настроенные задачи перенесите на удалённый Mac CI, а для большинства команд сначала запустите двухконтурную схему.

Кому нужен этот разбор

Вы получите пользу из статьи, если разрабатываете приложения для iOS, iPadOS или macOS и выбираете между управляемым сервисом Apple и собственным Mac-узлом.

Материал рассчитан на независимых разработчиков, руководителей мобильных команд, DevOps-инженеров и специалистов, отвечающих за подпись, сборку и выпуск релизов.

Быстрый выбор: стандартный процесс против полного контроля

Не начинайте с таблицы функций. Сначала ответьте на четыре вопроса:

1. Где находится исходный код и какие зависимости должны быть доступны во время сборки?
2. Нужен ли постоянный кэш или достаточно чистой среды на каждый запуск?
3. Требуются ли доступ к внутренней сети, фиксированный адрес или администраторские права?
4. Есть ли в цепочке Linux-задачи, межрепозиторная оркестрация или постоянный фоновый процесс?

Главная ошибка — сравнивать только длительность одной сборки. Быстрый запуск не показывает стоимость очереди, повторных прогонов, настройки секретов, восстановления после сбоя и сопровождения узла.

Оценка по пяти критериям

Для предварительной оценки поставьте каждому варианту балл от 0 до 2:

• 2 балла — решение закрывает требование без обходных путей;
• 1 балл — решение возможно, но требует проверки или ручного обслуживания;
• 0 баллов — требование противоречит модели среды.

Это не универсальный рейтинг производительности. Он показывает архитектурное соответствие. Если Xcode Cloud получает высокий балл по стандартным задачам, а удалённый Mac — по приватным и долгоживущим операциям, двухконтурная схема обычно требует меньше рискованных компромиссов.

Xcode Cloud для независимого разработчика и стандартного релиза

Xcode Cloud логично проверять первым, если у вас один или несколько Apple-проектов, обычный Xcode-проект, Git-репозиторий и понятный путь до TestFlight. Для начала нужен Apple Developer Program и удалённый Git-репозиторий; Apple также указывает Xcode 15.0 или более новую версию как требование для запуска. (developer.apple.com)

Внутри workflow можно запускать сборку, тесты, анализ и доставку. Apple описывает действия workflow как отдельные операции во временной среде, которая уничтожается после завершения сборки. Пользовательские build scripts поддерживаются, но это не превращает среду в постоянно настроенный сервер. (developer.apple.com)

Для независимого разработчика это означает:

• не требуется покупать отдельный Mac только ради редких сборок;
• не нужно самостоятельно устанавливать Xcode и следить за базовым окружением;
• расход можно наблюдать в App Store Connect;
• TestFlight и выпуск находятся рядом с процессом сборки.

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

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

Когда вычислительная квота становится отдельным фактором

Apple измеряет Xcode Cloud в вычислительных часах выполнения задач. В официальном примере пять тестовых запусков по 12 минут составляют один вычислительный час. Неиспользованный объём не переносится на следующий месяц. (developer.apple.com)

Актуальная опубликованная сетка Apple включает 25 часов в составе членства, а также планы на 100, 250, 1 000 и 10 000 часов в месяц. На странице Apple указаны цены 49,99 доллара США за 100 часов, 99,99 доллара за 250 часов, 399,99 доллара за 1 000 часов и 3 999,99 доллара за 10 000 часов. Перед расчётом бюджета проверьте официальную страницу: тарифы и доступность могут зависеть от региона. (developer.apple.com)

Чтобы сравнение было честным, соберите за один расчётный период следующие данные:

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

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

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

Для команды с частыми pull request, матрицей тестов и несколькими целями Apple важны не только минуты самой компиляции. Важнее, сколько заданий одновременно проходят обязательную проверку и сколько из них ждут исполнителя.

Xcode Cloud предназначен для параллельной сборки, тестирования и доставки приложений. Usage-панель Apple показывает число сборок, длительность и использование по приложениям, поэтому решение можно принимать по журналу, а не по впечатлению одного разработчика. (developer.apple.com)

Удалённый Mac CI даёт другой тип контроля. Вы можете назначить отдельный узел под релиз, другой — под nightly-тесты, а задания направлять по меткам. В системах с self-hosted Runner маршрутизация обычно опирается на группы и labels, включая операционную систему и архитектуру процессора. (docs.github.com)

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

Триггеры для изменения схемы

Оставляйте стандартные проверки в Xcode Cloud, пока одновременно выполняются три условия:

• обязательные зависимости доступны из workflow;
• очередь не задерживает слияние и выпуск;
• повторный запуск после сбоя не требует ручной настройки среды.

Добавляйте отдельный удалённый Mac-узел, если:

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

Не называйте это масштабированием только потому, что вы добавили ещё один Runner. Для каждого узла задайте владельца, политику обновления, срок хранения логов и процедуру вывода из эксплуатации.

Приватные зависимости и специальные скрипты: граница доступа

Xcode Cloud получает исходный код только для выполнения сборок, а временная среда уничтожается после завершения. Это удобно для воспроизводимости, но неудобно для компаний, где сборка зависит от внутренних адресов, VPN, закрытых сертификатов или локального сервиса. (developer.apple.com)

Проверяйте цепочку по отдельным звеньям:

1. Исходный код. Может ли workflow получить нужный commit без ручной передачи файлов?
2. Зависимости. Доступны ли Swift Package, CocoaPods, npm-пакеты или бинарные архивы?
3. Секреты. Подключаются ли сертификаты, provisioning profiles и API-ключи в допустимом формате?
4. Сетевые вызовы. Разрешены ли обращения к внутреннему DNS, API, зеркалу пакетов и хранилищу?
5. Скрипты. Работают ли команды без интерактивного ввода и администраторских прав?
6. Артефакты. Можно ли гарантированно вернуть IPA, dSYM, отчёты и логи?
7. Повторяемость. Проходит ли второй запуск после удаления локальных временных файлов?

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

Опытное правило: приватная зависимость должна быть проверена отдельно от подписи. Успешная авторизация в App Store Connect не доказывает, что сборочный узел видит внутренний пакетный реестр или сервис тестовой среды.

Первый этап: разделите обычный CI и постоянные задачи

Не отправляйте на один Mac всё, что называется автоматизацией. Обычная задача CI начинается с commit, выполняет сборку и тесты, возвращает артефакты и завершается. Ей нужна чистая и повторяемая среда.

Постоянная задача имеет другой профиль:

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

Для первого типа Xcode Cloud часто проще. Для второго удалённый Mac удобнее, но ответственность переходит к вам: обновление macOS и Xcode, контроль диска, перезапуск Runner, проверка процессов, изоляция секретов и восстановление после сбоя.

Самостоятельно размещённый Runner обычно требует, чтобы машина могла связываться с CI-платформой, имела достаточные ресурсы и поддерживаемую операционную систему. Если подходящего свободного исполнителя нет, задание остаётся в очереди; документация платформы указывает, что после длительного ожидания оно может завершиться ошибкой. (docs.github.com)

Пять шагов для безопасной двухконтурной проверки

Шаг 1. Выберите репрезентативный проект

Возьмите не демонстрационное приложение, а проект с реальными пакетами, тестами, подписью, экспортом и загрузкой тестовой сборки. Зафиксируйте commit, lock-файлы, версию Xcode и параметры конфигурации.

Шаг 2. Разделите задания по риску

Отметьте, какие действия являются стандартными:

• compile;
• unit tests;
• UI tests;
• archive;
• экспорт и передача тестировщикам.

Отдельно вынесите внутренние API, приватные зависимости, генерацию кода, нестандартные CLI-инструменты и операции, требующие постоянного состояния.

Шаг 3. Запустите одинаковые задания

Один и тот же commit выполните в Xcode Cloud и на удалённом Mac CI. Не меняйте порядок скриптов, ключи подписи, параметры сборки и набор тестов. Иначе вы сравните разные процессы, а не две среды.

Шаг 4. Запишите не только время

В таблицу наблюдений внесите:

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

Шаг 5. Сформулируйте условия сохранения и отката

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

Итоговая матрица решения для команды

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

Что выбрать небольшой команде: Xcode Cloud или собственный Mac CI?

Для стандартного Xcode-проекта и редких релизов начните с Xcode Cloud. Собственный Mac CI имеет смысл, когда приватная сеть, постоянный кэш или специальные инструменты уже являются обязательными, а не предполагаемыми требованиями.

Можно ли подключить Xcode Cloud к внутренним зависимостям компании?

Проверяйте каждый сетевой маршрут отдельно. Доступ к исходному коду не означает доступ к внутреннему DNS, VPN, пакетному реестру или API. Если зависимость доступна только внутри сети компании, собственный или удалённый Mac-узел обычно проще контролировать.

Подходит ли удалённый Mac CI для постоянных пользовательских скриптов?

Подходит, если скриптам действительно нужны сохранённое состояние, установленные инструменты или длительный процесс. Однако узел придётся обновлять, очищать, мониторить и восстанавливать. Простые скрипты лучше оставить в одноразовом CI workflow.

Как сравнить вычислительное использование Xcode Cloud с фиксированным Mac-узлом?

Сопоставляйте месячные журналы, а не одну сборку. Учитывайте вычислительные часы, ожидание, повторы, аренду, обслуживание, хранение кэша и время инженера. Фиксированный узел может быть выгоднее по контролю, даже если не используется каждую минуту.

Можно ли одновременно использовать Xcode Cloud и самостоятельно размещённый Runner?

Да. Стандартные проверки можно оставить в Xcode Cloud, а приватные зависимости, нестандартные инструменты и межсистемные этапы направить на отдельный Mac-узел. Для маршрутизации нужны явные метки, группы, правила доступа и владелец каждого исключения.

Если текущая схема построена вокруг Linux-узла или виртуальной macOS, её слабые места обычно проявляются в отсутствии полноценного Apple-инструментария, нестабильном доступе к подписи, ручном обслуживании образов и ограничениях сетевого маршрута. Для задач, где нужна реальная macOS-среда с управляемым доступом, можно изучить тарифы на bare-metal macOS и отдельно сравнить физический Mac с виртуализацией macOS. Такой вариант не отменяет Xcode Cloud и не является лучшим решением для каждой команды, но позволяет проверить собственные сборочные задачи на отдельном Mac без немедленной покупки оборудования.

Перед окончательным переносом откройте доступные у MacDate Mac-узлы для аренды, выберите подходящий период и повторите на нём тот же набор compile, test, signing и delivery-задач. Решение принимайте по журналу успешности, восстановлению после перезапуска и объёму ручного обслуживания, а не по обещанию фиксированной скорости.