Сборка заканчивается, пока следующая задача всё ещё ждёт свободную среду, или тестирование использует те же ключи подписи, что и публикация.

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

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

Начните с реального пересечения задач, а не с числа приложений

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

Для решения запишите время постановки каждого задания в очередь, время старта и завершения, а также причину повторного запуска, если он понадобился. Так видно, где именно возникает ожидание: предыдущая сборка ещё занимает Mac, workflow настроен на последовательное выполнение, нужный Runner недоступен или конкретная задача не может безопасно использовать общую среду.

Важно не путать три вещи: количество задач в очереди, число одновременно работающих процессов и количество изолированных Mac-сред. Увеличение последнего не исправит ограничения workflow автоматически, а разрешённый параллелизм не гарантирует, что конкретный Mac, набор ключей или версия Xcode смогут безопасно обслуживать все задания.

Одному приложению обязательно нужен отдельный сервер сборки?

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

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

Ситуация Что проверить Предварительный выбор
Один разработчик, редкие сборки Возникает ли очередь регулярно и влияет ли ожидание на работу Одна Mac-среда, пока нет повторяющихся конфликтов
Несколько приложений, сборки идут по очереди Совпадают ли Xcode, зависимости, настройки подписи и требования проектов Общая среда допустима после проверки каждого проекта
Несколько авторов, задачи совпадают по времени Какие задания ждут, кто их запускает и можно ли безопасно выполнять их последовательно Настроить очередь; параллельную среду оценивать по журналу ожидания
Тестирование и публикация имеют разные полномочия Нужны ли отдельные сертификаты, доступы, обязанности и правила кода Рассматривать изоляцию независимо от числа задач

Это ориентир для выбора сценария, а не обещание, что проекты с похожим расписанием совместимы. Разные версии Xcode, SDK, зависимости, настройки подписи и требования к macOS могут потребовать отдельных конфигураций. Перед объединением проверьте фактические требования каждого проекта по официальной таблице системных требований Xcode.

Выберите схему под профиль работы

Несколько приложений можно собирать на одном Mac?

Несколько приложений могут использовать общую Mac-среду, если их задачи в основном идут по очереди и проверка подтвердила совместимость инструментов, зависимостей и подписания. Число проектов не показывает, будут ли они бороться за ресурсы: приложения, которые собираются в разное время, могут не создавать параллельной нагрузки.

Перед объединением составьте короткую карту каждого проекта: требуемая версия Xcode и macOS, набор пакетов и иных зависимостей, схема сборки и тестирования, а также нужные сертификаты и права доступа. Если одному проекту необходима версия инструмента, которую нельзя использовать в другом, или правила доступа несовместимы, общего расписания может быть недостаточно — понадобится отдельная конфигурация либо изоляция. Не делайте вывод о совместимости только потому, что оба репозитория содержат iOS-приложение.

Что сопоставить между проектами Когда общая среда выглядит разумно Когда следует проверить отдельную среду
Версия Xcode и требования macOS Используемые версии можно поддерживать в общей конфигурации Нужные версии или системные требования конфликтуют
Зависимости и параметры сборки Переключение конфигурации воспроизводимо и проверено Состояние одного проекта может повлиять на сборку другого
Сертификаты и полномочия Одна ответственность и допустимая общая область доступа Разные владельцы выпуска или разные границы доверия
Расписание заданий Работы обычно выполняются последовательно Задания пересекаются и задержки мешают поставке

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

Команде сначала нужно разделить ожидание и границы доверия

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

Отдельный вопрос — код и секреты. Самостоятельный Runner, используемый несколькими заданиями, требует осторожного отношения к доверию: официальные рекомендации GitHub предупреждают о рисках запуска на self-hosted Runner кода из недоверенных workflow. Поэтому решение об изоляции нужно связывать с источником заданий и доступом к секретам, а не только с желанием сократить очередь. Ознакомьтесь с рекомендациями по безопасному использованию self-hosted Runner и отдельным описанием рисков workflow с pull_request_target.

Проверьте и полномочия участников в контуре публикации. У Apple Developer Program предусмотрены разные роли и уровни доступа; значит, распределение релизных действий следует соотнести с назначенными правами, а не просто передать всем общий доступ к одной среде. Сверьте рабочую схему с описанием ролей Apple Developer Program. Если по фактической модели ответственности тестировщикам не нужны релизные полномочия, не расширяйте их только ради удобства общей сборки.

Тип задания Что обычно важнее Решение для оценки
Доверенная тестовая сборка Удобная очередь и понятные результаты Общая среда возможна, если требования совместимы
Проверка кода с неизвестным уровнем доверия Защита секретов и изоляция от релизных данных Отдельно проверить безопасность и права запуска
Архивирование и подготовка публикации Контроль сертификатов, полномочий и ответственности Определить отдельный релизный контур, если границы доступа этого требуют
Одновременные независимые задания Влияние ожидания на проверку и выпуск Сначала подтвердить конкуренцию по журналу, затем оценить отдельную среду

Разделите сборку, тестирование и публикацию по их назначению

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

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

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

Проверьте, что именно ограничивает GitHub Actions

GitHub Actions управляет параллельностью задач с помощью групп concurrency. Поведение очереди и одновременного выполнения определяется настройками workflow и concurrency-групп; поэтому наличие нескольких заданий в интерфейсе не является доказательством, что Mac не справляется. Перед покупкой дополнительной среды проверьте, не настроена ли последовательность намеренно и не ожидает ли задание из-за правил оркестрации. Подробности описаны в документации GitHub Actions о concurrency.

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

Отдельно оцените возможности конкретного инструментария. Например, примечания к выпуску Xcode 27 указывают, что эту версию можно устанавливать и запускать только на Mac с Apple silicon; точный набор поддерживаемых систем, SDK и устройств сверяйте с примечаниями Xcode 27 и актуальной таблицей требований Xcode. Это факт о совместимости инструмента, а не рекомендация иметь определённое количество Mac.

Примите решение по наблюдаемым условиям

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

  • Если задания обычно не совпадают по времени и ожидание не мешает проверке или выпуску — оставьте одну среду и продолжайте записывать очереди. Не добавляйте Mac только потому, что проектов стало больше.
  • Если независимые задания повторно ждут занятый Runner и ожидание сдвигает рабочие этапы — проверьте concurrency, метки и ограничения среды; если причина действительно в занятой общей машине, оцените отдельный Runner или Mac.
  • Если тестовые задания не должны иметь доступа к публикационным секретам — сначала определите требуемую границу доверия и полномочий, затем спроектируйте отдельный контур. Не выдавайте общий доступ ради ускорения.
  • Если проект требует несовместимой версии Xcode, macOS или набора зависимостей — подтвердите это на практике и рассмотрите отдельную конфигурацию. Не предполагайте, что установка дополнительного Mac сама по себе решит проблему управления версиями.
  • Если задержка вызвана настройкой workflow или отсутствующей меткой Runner — сначала исправьте маршрутизацию или правила очереди. Добавление оборудования без исправления причины может оставить задания в ожидании.
  • Если реальные задания редко пересекаются, а отдельные полномочия не нужны — сохраните общую среду. Периодически пересматривайте решение, если изменились график релизов, команда или требования инструментов.

Проверьте представительный процесс до расширения

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

Порядок проверки:

  • Зафиксируйте профиль задания. Укажите репозиторий и ветку, источник запуска, требуемые Xcode и macOS, зависимости, тестовую схему и тип результата.
  • Проверьте получение кода. Убедитесь, что Runner получает нужную версию проекта и не использует случайное локальное состояние, оставшееся от предыдущего задания.
  • Выполните сборку и тесты. Сверьте результат с ожидаемым для команды, сохраните журнал ошибок и отметьте, мешали ли параллельные работы.
  • Отдельно испытайте публикационный этап, если он входит в задачу. Подтвердите наличие необходимых полномочий и секретов, но не предоставляйте их тестовым заданиям без обоснования.
  • Сопоставьте результаты общей и изолированной среды. Проверьте не только успешный финал, но и маршрут задания, версию инструментов, доступы и причину ожидания.
  • Обновите схему по обнаруженным фактам. Если проблема связана с очередью — настройте исполнение; если с доверительной границей — разделите доступ; если с совместимостью — зафиксируйте отдельную конфигурацию.

Для Xcode 27 дополнительно подтвердите совместимость выбранного Mac и версии macOS по официальным требованиям: релизные примечания ограничивают установку этой версии Mac с Apple silicon. Не переносите это ограничение на другие версии Xcode без проверки их собственных требований.

При аренде удалённого Mac такую проверку стоит провести до того, как переносить на него постоянную сборку или публикацию. У RUVCLOUD доступны недельные, месячные и квартальные периоды аренды, а удалённый доступ предусмотрен через VNC, SSH или веб-консоль; характеристики конкретного предложения нужно сверять на странице тарифов RUVCLOUD. Сам факт удалённого доступа не подтверждает совместимость вашего проекта — её устанавливает только прогон представительной задачи с нужными версиями, зависимостями и правами.

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