Симптом: текущие Intel Mac стабильно собирают релизы, но Xcode 27 уже нельзя установить и запустить на этой архитектуре. Самое быстрое решение: не останавливайте Intel-пул и не выводите его из эксплуатации одномоментно — оставьте Xcode 26.6 для производства, а Xcode 27 перенесите в отдельный пул Apple Silicon и допускайте его к релизам только после двойного прогона.
Этот план предназначен для IT-руководителей, отвечающих за iOS CI/CD, Xcode и парк Intel Mac. Он также подходит командам разработки, которым нужно проверить скрипты, бинарные зависимости и цепочку подписи, а техническим директорам — сравнить покупку, аренду или смешанную инфраструктуру.
Последнее обновление: 24 августа 2026 года. Статус Xcode и системные требования сверены по официальным материалам Apple Developer; поведение runner проверяется по документации соответствующей CI-платформы.
Сначала зафиксируйте архитектурную границу
По состоянию на 24 августа 2026 года Xcode 27 находится в статусе Beta 5, а официальные примечания Apple прямо указывают, что он устанавливается и работает только на Mac с Apple Silicon — это не ограничение конкретного проекта или настройки CI, а требование самого инструментария. Проверяйте актуальный статус в разделе релизов Apple Developer и в примечаниях к Xcode 27 Beta 5.
Xcode 26.6 был выпущен 25 июня 2026 года, что подтверждено в официальном сообщении о релизе Xcode 26.6. Поэтому рабочее решение на текущем этапе выглядит так:
| Пул | Архитектура | Роль | Решение |
|---|---|---|---|
| Производственный | Intel Mac | Существующие сборки на Xcode 26.6 | Временно сохранить |
| Проверочный | Apple Silicon | Проверка Xcode 27, SDK, тестов и подписи | Создать отдельно |
| Переходный | Apple Silicon и Intel Mac | Двойной прогон одного коммита | Использовать до допуска к переключению |
Триггерами для запуска проекта могут быть необходимость тестировать новый SDK, приближение внутреннего окна релиза, рост риска отказа старых устройств или требование поддерживать SLA публикации. Но сам триггер не означает немедленного отключения Intel Mac.
Зафиксируйте четыре недели работ, а не число устройств
Ниже приведён рекомендуемый график проекта на четыре недели. Это не обещание Apple и не нормативный срок, а рабочий календарь, который вы можете сжать или растянуть в зависимости от числа пайплайнов, окна релиза и количества неизвестных зависимостей.
| Период | Основная работа | Доказательство готовности | Если не пройдено |
|---|---|---|---|
| Неделя 1 | Инвентаризация Intel Mac и пайплайнов | Полный реестр задач, версий и владельцев | Заморозить расширение пула, закрыть пропуски |
| Неделя 2 | Изолированный пилот Apple Silicon | Невыпускающие задачи проходят на новом runner | Оставить узел вне production |
| Неделя 3 | Двойной прогон Intel и Apple Silicon | Совпадают тесты, архив, подпись и экспорт | Найти расхождение, включить откат |
| Неделя 4 | Поэтапное переключение | Реальные задачи проходят с работающим fallback | Вернуть трафик в Intel-пул |
Шаг 1. Составьте реестр Intel Mac
Для каждой машины внесите в таблицу:
- идентификатор узла и его CI-тег;
- пайплайны, которые имеют право запускаться на узле;
- установленную версию Xcode и способ её выбора;
- целевые платформы и типы задач;
- операции с сертификатами, provisioning profile и Keychain;
- зависимости от внутренних репозиториев и сервисов;
- пиковую очередь и допустимое время ожидания;
- владельца пайплайна и ответственного за откат.
| Что проверять | Пример записи | Почему это влияет на миграцию |
|---|---|---|
| Инструмент | Xcode, Swift, генератор проекта | Версия может менять предупреждения и результат сборки |
| Бинарная зависимость | Только x86_64 | Потребуется Universal binary, arm64-сборка или переходный режим |
| Скрипт | Вызов внешнего CLI | Путь, права и архитектура процесса могут отличаться |
| Подпись | Сертификат, профиль, Keychain | Успешная компиляция не доказывает готовность релиза |
| Очистка | Derived Data, временные каталоги | Остаточный кэш способен скрыть проблему миграции |
| Доступ | Git, приватный registry, API | Новый узел должен иметь минимально необходимый доступ |
Проверьте, почему Xcode 27 не устанавливается на Intel Mac
Причина не в том, что Intel Mac внезапно перестал выполнять старые сборки. Xcode 27 имеет подтверждённую границу поддержки Apple Silicon, поэтому попытка перенести на Intel тот же установочный пакет, изменить тег runner или оставить старый образ не создаёт совместимый узел. В результате вы получите не исправление пайплайна, а отложенную ошибку на уровне среды.
Разделяйте три решения:
- Миграция версии Xcode — проект начинает проверяться новым SDK и инструментами.
- Миграция архитектуры CPU — сборка переносится с Intel на Apple Silicon.
- Вывод оборудования из эксплуатации — старый узел лишается задач, учётных данных и данных.
**Важно.** Xcode 26.6 — это переходный производственный пул, а не доказательство долгосрочной совместимости Intel. Не расширяйте его роль новыми задачами, если они уже требуют Xcode 27 или нового SDK.
За две недели до пилота создайте изолированный Apple Silicon узел
Пилотный узел подключайте сначала к очереди без подписи и публикации. Не переносите на него постоянную учётную запись администратора, общий Keychain и все production-секреты. Для задач, которым требуется подпись, создайте отдельный управляемый путь доступа и заранее определите, кто может его использовать.
Для каждой CI-платформы заново настройте:
- runner или agent с отдельной меткой архитектуры;
- правило выбора Xcode;
- установку зависимостей;
- очистку workspace и временных каталогов;
- сохранение логов и артефактов;
- удалённую перезагрузку и возврат узла в очередь.
Набор пилотных задач должен включать Swift и Objective-C, обычную сборку, модульные и UI-тесты, архивирование, экспорт и обращение к внутренними зависимостями. Если одна компиляция прошла успешно, это подтверждает только один слой. Отдельно проверяйте чистое окружение, повторный запуск после ошибки и восстановление после удалённой перезагрузки.
Что именно проверять при переходе iOS CI/CD с Intel на Apple Silicon
Переход iOS CI/CD между архитектурами нужно оценивать по артефакту и поведению пайплайна, а не только по времени компиляции. В двойной прогон отправляйте один и тот же commit в оба пула. Сравнивайте:
- код возврата каждой стадии;
- предупреждения и ошибки компилятора;
- набор и результаты тестов;
- состав архива;
- экспорт IPA и параметры конфигурации;
- подпись, provisioning profile и проверку entitlements;
- публикационные проверки;
- очистку workspace после завершения;
- работу внутренних CLI и бинарных зависимостей.
| Область двойного прогона | Критерий допуска | Действие при расхождении |
|---|---|---|
| Компиляция | Один commit даёт ожидаемый результат в обоих пулах | Проверить SDK, флаги и архитектурные условия |
| Тесты | Нет необъяснимых пропусков и новых падений | Повторить на чистом workspace, затем локализовать зависимость |
| Архив и экспорт | Архив проходит внутренние проверки и экспортируется | Сравнить настройки схемы и export options |
| Подпись | Сертификат, profile и entitlements соответствуют политике | Не переводить задачу в release-пул |
| Внешние бинарники | Все критичные инструменты работают в целевой архитектуре | Найти arm64-замену или документировать переходный режим |
| Восстановление | Узел возвращается в очередь после перезагрузки | Оставить задачу в пилоте до исправления автоматики |
Нужно ли использовать Rosetta как постоянное решение
Rosetta можно рассматривать только как переходный механизм для конкретной x86_64-зависимости, если она проверена в вашем сценарии. Она не превращает весь Apple Silicon узел в эквивалент Intel Mac и не устраняет проблемы с путями, установщиками, плагинами, подписью или неподдерживаемыми инструментами.
В реестре укажите, какой процесс запускается в переходном режиме, кто владеет его заменой и до какой даты он разрешён внутренней политикой. Если зависимость участвует в подписании или публикации, её нельзя считать безопасной только потому, что тестовая сборка завершилась успешно.
За неделю до переключения оформите допуск и откат
До окна миграции создайте короткую таблицу допуска для каждого критичного пайплайна. В ней должны быть ссылки на логи двойного прогона, результаты тестов, подтверждение подписи, список временных исключений и назначенный владелец.
- [ ] Для каждой production-задачи указан целевой Apple Silicon runner.
- [ ] Для старой задачи сохранён рабочий маршрут на Intel с Xcode 26.6.
- [ ] Один и тот же commit проверен в обоих пулах.
- [ ] Чистая сборка и повторный запуск после ошибки завершены без необъяснимых различий.
- [ ] Архив, экспорт, подпись и entitlements проверены отдельно.
- [ ] x86_64-зависимости классифицированы: заменены, разрешены временно или заблокированы.
- [ ] После удалённой перезагрузки узел возвращается в очередь без ручного входа.
- [ ] Для каждой стадии задано условие возврата в Intel-пул.
- [ ] Ответственный за решение об остановке миграции доступен в окне релиза.
- [ ] Секреты, аккаунты и права нового узла соответствуют принципу минимального доступа.
Если результат отличается, не исправляйте одновременно код, кеш, Xcode и runner. Зафиксируйте исходный commit, очистите окружение и повторите задачу. Затем разделите причину на пять классов: инструмент, архитектурное условие, кэш, скрипт или сторонний бинарный файл. Такое разделение сокращает риск принять случайное повторное прохождение за исправление.
Как выбрать покупку, аренду или смешанный пул
После инвентаризации вы уже знаете не только требуемое число узлов, но и характер нагрузки: постоянная, сезонная, аварийная или связанная с единичным окном миграции. Это основа сравнения TCO.
| Вариант | Когда подходит | Скрытые обязательства | Роль в миграции |
|---|---|---|---|
| Покупка Apple Silicon | Нагрузка стабильна, узел нужен длительное время | Закупка, доставка, гарантия, замена, резервирование и вывод из эксплуатации | Постоянный production-пул |
| Аренда удалённого Mac | Нужен быстрый пилот или временная ёмкость | Контроль доступа, сетевой маршрут, перенос секретов и правила завершения аренды | Проверочный или переходный пул |
| Смешанная схема | Часть задач постоянна, пики и миграция непредсказуемы | Две модели эксплуатации и единые политики CI | Базовый пул плюс эластичный резерв |
Если вам нужен удалённый Apple Silicon для проверки собственного проекта, сначала изучите руководство по работе с Mac на Apple Silicon, а затем сопоставьте условия аренды Mac на нужный период. Выбор узла делайте после проверки очереди, восстановления и сетевого доступа, а не по одному названию чипа.
Переведите узлы поэтапно и отдельно выведите Intel из эксплуатации
В день переключения изменяйте маршрутизацию небольшими партиями. После PR-задач перенесите тесты, затем архивирование и публикацию. Каждый этап должен иметь сохранённый fallback: понятный тег Intel-пула, владельца решения и процедуру возврата без ручного переписывания всего пайплайна.
В течение первого месяца после миграции собирайте факты по четырём направлениям:
- доля успешных задач и причины повторных запусков;
- очередь и время подготовки окружения;
- случаи расхождения артефактов и подписи;
- восстановление после перезагрузки, потери сети или сбоя зависимости.
Вывод старой машины — отдельная процедура. Отзовите CI-токены, сертификаты и профили, удалите учётные записи, проверьте архивы и логи, зафиксируйте владельца данных и выполните уничтожение локальных секретов по корпоративной политике. После этого удалите узел из CI, инвентаря и систем мониторинга. Простого выключения питания недостаточно: доступ к старому Keychain или оставшемуся runner-токену может сохранить путь к production.
Когда аренда Apple Silicon разумнее немедленной закупки
Если после аудита вам требуется только доказать совместимость, а постоянный объём задач ещё неизвестен, покупка всего нового пула создаёт преждевременный TCO-риск. Вы заплатите за оборудование до того, как поймёте реальную очередь, долю зависимостей Rosetta, требования к восстановлению и число задач, которые действительно нуждаются в Xcode 27.
Удалённый Mac в аренду удобен как изолированный проверочный узел: вы подключаете его к непроизводственной очереди, используете собственные проекты и получаете доказательства, на которых можно строить закупку или смешанную схему. При этом аренда не заменяет постоянную инфраструктуру для непрерывной тяжёлой нагрузки, если вам нужны физические интерфейсы, локальное сетевое подключение или долгий срок эксплуатации с предсказуемой загрузкой.
Для команды, которая уже завершила аудит и хочет проверить временную Apple Silicon-ёмкость, страница MACGPU может быть отправной точкой для согласования такого пилота. Сначала зафиксируйте критерии приемки и срок проверки, затем выбирайте способ размещения.
Если текущие Intel Mac оставить без плана, вы получите сразу несколько проблем: Xcode 27 останется недоступным, старые узлы будут продолжать потреблять время на обслуживание, а команда не соберёт доказательств совместимости до критического окна релиза. Полная закупка Apple Silicon без двойного прогона, напротив, переносит риск в бюджет и не гарантирует, что скрипты, подпись и внутренние бинарники заработают. Для временного перехода или проверки собственного iOS CI/CD разумнее сначала арендовать изолированный Apple Silicon Mac, собрать реальные данные по очереди и восстановлению, а затем принять обоснованное решение о покупке, длительной аренде или смешанном пуле.