Xcode 27 переходит на macOS 27: список миграции CI в 2026

На этой неделе не переводите production на метку xcode-27: сначала сохраните прежний CI-контур и поднимите фиксированный удалённый Mac с тем же Xcode для сравнения с macOS 27. Это особенно важно потому, что GitHub подтвердил смену хостовой системы, а xcode-27 и xcode-27-xlarge по состоянию на 14 сентября 2026 года всё ещё имеют статус Public Preview (сообщение GitHub о переходе Runner на macOS 27).

Эта статья для вас, если вы поддерживаете workflow xcode-27, отвечаете за GitHub Actions и должны понять, что именно сломалось: проект, Xcode 27, зависимости или macOS 27.

Она также предназначена для DevOps-инженеров и руководителей мобильной платформы, которым нужны доказательства для допуска нового Runner, понятный откат и отдельная среда с контролируемой версией macOS.

Последнее обновление — 14 сентября 2026 года. Данные сверены по GitHub Changelog, документации GitHub Actions, списку образа xcode-27, требованиям Apple к Xcode и примечаниям к выпуску Xcode 27.

Исходная точка: изменился не только Xcode

Главная ошибка этой миграции — считать xcode-27 обычным обновлением инструмента. Метка указывает на набор окружения, но не является гарантией, что между запусками меняется только Xcode. GitHub подтвердил, что образы xcode-27 и xcode-27-xlarge с 10 сентября 2026 года работают на macOS 27 и пока находятся в Public Preview (официальная запись GitHub Changelog).

Это создаёт сразу несколько независимых источников риска:

• системные пути и встроенные утилиты могут отличаться от прежнего хоста;
• Homebrew, Ruby, Python, Node.js, плагины и другие бинарные зависимости могут иметь предположения об архитектуре или версии системы;
• Simulator способен изменить доступность runtime, запуск тестового приложения и формат вывода;
• ключи, связка ключей, подпись и экспорт архива могут вести себя иначе, даже если исходный код не изменился;
• сторонние Actions могут ссылаться на путь или пакет, которого нет в новом образе;
• плавающий preview-образ усложняет доказательство того, что повторный запуск использовал ту же среду.

Сверяйте не только название Runner, но и фактическую версию образа, список установленного ПО и активный Developer Directory. Для этого пригодятся список программного состава образа xcode-27 и журнал конкретного задания.

Два контура до решения о допуске

GitHub описывает размещённые Runner как временные вычислительные среды, а self-hosted Runner позволяет контролировать собственный узел и его окружение (документация GitHub-hosted Runner, документация self-hosted Runner). Для этой миграции важна не абстрактная разница моделей размещения, а возможность воспроизвести тот же сценарий на системе, которую вы не меняете между тестами.

До переключения: производственная базовая линия

Перед первым запуском на macOS 27 выберите последний успешный production-job и сохраните его как контрольный пакет. Не ограничивайтесь ссылкой на страницу задания: через время часть контекста может быть недоступна, а повторный запуск уже не будет точной копией исходной среды.

В пакет должны войти:

• commit или tag проекта;
• имя workflow, repository, Scheme и destination;
• фактическая версия Runner image;
• версия macOS и архитектура узла;
• версия Xcode и значение xcode-select;
• lock-файлы Swift Package Manager, CocoaPods, Bundler, npm или других используемых менеджеров;
• параметры xcodebuild, переменные окружения и настройки кеша;
• журнал сборки, xcresult, архив и результат проверки подписи;
• сведения о способе публикации, но без копирования секретов в открытый лог.

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

Правило сравнения должно быть жёстким: в первой проверке нельзя одновременно менять зависимости, сертификаты, Scheme и скрипты. Если вы обновите всё сразу, успешный или неуспешный результат не покажет причину. Зафиксируйте исходный commit и lock-файлы, а затем меняйте только слой, который вы проверяете.

Момент первого запуска: фактическая среда

Не делайте вывод о macOS только по YAML. Добавьте в диагностическую часть workflow вывод фактически выбранной среды:

sw_vers
uname -m
xcode-select -p
xcodebuild -version
xcrun simctl list runtimes
env | sort

Значения окружения следует фильтровать от токенов, сертификатов и других секретов. В логе должны остаться версия системы, архитектура, активный Developer Directory, версия Xcode и список доступных Simulator runtime. Сверяйте их с README образа и с записью задания, а не с ожидаемым значением в конфигурации.

Затем выполните минимальную задачу:

xcodebuild \
  -workspace "<WORKSPACE>.xcworkspace" \
  -scheme "<SCHEME>" \
  -sdk iphoneos \
  -configuration Debug \
  CODE_SIGNING_ALLOWED=NO \
  build

Замените <WORKSPACE> и <SCHEME> на значения вашего проекта. Эта команда не доказывает готовность релиза, но помогает отделить базовую компиляцию от подписи и доставки.

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

Первый час: зависимости и архитектура

После базовой компиляции проверьте элементы, которые часто скрывают привязку к старой системе. Ищите не только ошибки Swift или Objective-C, но и жёстко заданные пути:

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

Для каждого бинарного файла, который участвует в сборке, определите архитектуру:

file "<PATH_TO_BINARY>"

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

Проблемные Intel-only компоненты, нестандартные плагины и скрипты с системными проверками вынесите в отдельный список. Если исправление нельзя безопасно проверить в рамках текущего запуска, отправьте тот же commit на фиксированный удалённый Mac. Такой узел полезен не как «более быстрый компьютер», а как контрольная среда с неизменяемой связкой macOS и Xcode.

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

Полная сборка: от компиляции к Simulator

Успешный Archive ещё не означает, что миграция завершена. Пройдите проверки в порядке, который позволяет локализовать слой отказа:

1. выполните сборку без подписи для основного SDK;
2. запустите unit-тесты без публикации;
3. проверьте запуск тестового приложения в Simulator;
4. соберите результат в xcresult;
5. прогоните существующий скрипт разбора отчёта;
6. сравните предупреждения, тестовые результаты и артефакты с базовой линией.

Пример запуска тестов:

xcodebuild \
  -workspace "<WORKSPACE>.xcworkspace" \
  -scheme "<SCHEME>" \
  -destination 'platform=iOS Simulator,name=<SIMULATOR_NAME>,OS=<RUNTIME>' \
  test \
  -resultBundlePath "<RESULT_BUNDLE>.xcresult"

Имена устройства и runtime оставьте параметрами workflow, а не вписывайте в статью или внутреннюю документацию как универсальные значения. Доступность конкретного Simulator нужно подтверждать в текущем образе командой xcrun simctl list runtimes; перечень программного состава и инструментов меняется вместе с образом и должен сверяться с официальным README xcode-27.

Проверьте четыре признака, которые часто пропускают:

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

Если ошибка появляется только на Simulator, не называйте её общей несовместимостью Xcode. Сначала сопоставьте runtime, destination, архитектуру тестового процесса и доступные системные компоненты. Причину следует связывать с Xcode 27 или macOS 27 только после сравнения с контрольным узлом и проверки соответствующего раздела официальных release notes.

Отдельная фаза: подпись и доставка

Подпись нельзя проверять первым шагом на preview Runner. Используйте тестовое приложение, непроизводственный сертификат или другой контролируемый набор учетных данных, согласованный с вашей политикой безопасности. Проверяйте последовательно:

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

Команды и идентификаторы в документации должны оставаться параметрами: <TEAM_ID>, <BUNDLE_ID>, <PROFILE_NAME>, <ARCHIVE_PATH>. Не публикуйте реальные названия аккаунтов, repository, Scheme, сертификатов и устройств.

Любое удаление сертификата, перестроение связки ключей или принудительная замена настроек подписи сначала оформите как отдельное изменение с описанием области воздействия и способом восстановления. Если preview-запуск неожиданно меняет состояние ключей, остановите его и вернитесь к чистому тестовому узлу. Производственная связка не должна становиться экспериментальным объектом только потому, что компиляция прошла.

Apple отдельно документирует требования и изменения Xcode, поэтому перед допуском кандидата сопоставьте результаты с Xcode 27 Release Notes. Документ не заменяет ваши логи: он объясняет ожидаемое поведение, а журнал показывает, что произошло именно в вашем workflow.

Матрица решения: миграция, двойной контур или откат

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

FAQ: спорные точки миграции

Почему xcode-27 оказался на macOS 27

Причина подтверждена GitHub: с 10 сентября 2026 года образы xcode-27 и xcode-27-xlarge запускаются на macOS 27. Это изменение образа Runner, а не только установка Xcode 27 поверх прежнего хоста. Статус Public Preview сохраняется, поэтому дату перехода в GA и окончательный состав программного обеспечения нельзя считать известными.

Что делать при сбое после обновления Xcode 27

Начните с фактического лога: macOS, версия образа, архитектура, xcode-select, Xcode и runtime Simulator. После этого выполните минимальный xcodebuild без подписи. Если он падает, сохраните артефакты и остановите перевод production. Если он проходит, переходите к тестам, Simulator и только потом к подписи, меняя один слой за раз.

Как сравнить влияние Xcode и macOS

Создайте пару узлов: preview Runner с macOS 27 и фиксированный удалённый Mac с согласованной прежней системой. На обоих запускайте одинаковый commit, Scheme, lock-файлы и команды. Одинаковый сбой указывает на проект или Xcode, различие при одинаковом Xcode — на хостовую macOS, окружение или установленный компонент.

Подходит ли preview Runner для публикации

На 14 сентября 2026 года это не следует считать безопасным production-основанием: оба образа остаются Public Preview. Их можно использовать для контролируемой проверки и раннего обнаружения проблем, но официальный выпуск лучше оставить на прежнем маршруте, пока не проверены подпись, экспорт, артефакты и возврат к стабильному узлу.

Как удерживать macOS 26 для сравнения

Используйте отдельный удалённый Mac, на котором зафиксированы версия системы, Xcode, архитектура и зависимости. Отключите самовольные обновления и не меняйте одновременно сертификаты или скрипты. Запускайте тот же commit и сохраняйте журналы, xcresult, архив и сведения о перезапуске. Такой узел становится доказательным ориентиром, а не случайной резервной машиной.

Первая неделя: критерии допуска

В день перехода сохраняйте старую производственную линию. В следующие запуски отправляйте на новый Runner только ограниченную долю задач, которые не выполняют официальный выпуск. Каждый результат связывайте с версией образа, commit и типом проверки. Если GitHub меняет preview-статус, macOS, метку или список программ, проводите повторную сверку до следующего расширения.

На протяжении первой недели отслеживайте:

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

Если сбой появляется только на macOS 27, не пытайтесь замаскировать его повторной установкой зависимостей. Оставьте Xcode 27 на контролируемом удалённом Mac, продолжайте двойной контур и заведите отдельную задачу на устранение причины. Если все ключевые проверки проходят, артефакты сравнимы, а rollback проверен, увеличивайте долю задач поэтапно.

Срок хранения старого workflow задайте как операционное правило команды, а не как календарное обещание. Его нельзя удалять, пока не подтверждены повторяемость, подписанный артефакт, публикация и восстановление после отказа. Повторная оценка обязательна при изменении статуса Preview, хостовой macOS, состава образа, версии Xcode или правил подписи.

Что выбрать для вашей CI-схемы

Если вам важна эластичность и вы готовы принимать изменения preview-образа, GitHub Actions подходит для ранней проверки. Если релиз зависит от конкретной связки macOS и Xcode, одной метки xcode-27 недостаточно: вам нужен зафиксированный контрольный узел. Если команда не может быстро восстановить сертификаты, Simulator или отчёты, двойной контур безопаснее прямого переключения.

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

Если после пилота вам нужен именно такой контроль, можно рассмотреть аренду удалённого Mac для Xcode и CI: сначала воспроизведите один критичный workflow на фиксированной системе, затем сравните его с xcode-27 и только после этого меняйте production-маршрут. Это полезнее, чем принимать решение по одному успешному запуску.

Ваш рабочий план на сейчас: зафиксировать базовую линию, проверить реальный хост, выполнить минимальную сборку, пройти Simulator и подпись на тестовых данных, а затем сохранить старый путь как rollback. До подтверждения всех этих этапов рассматривайте macOS 27 как preview-слой миграции, а не как незаметную замену прежнего Runner.