Xcode 27: самостоятельный Runner GitHub Actions

На 31 июля 2026 года для Xcode 27 следует выбирать двойную миграцию, а не полную замену production-ноды: сохраните стабильный Runner с Xcode 26.6 и добавьте отдельный Apple Silicon Mac с Xcode 27 beta. Переключать основной инструмент можно только после успешной проверки сборки, тестов, подписи и архивации на реальном проекте.

Такой порядок подходит тем, кто отвечает за iOS или macOS CI/CD, переносит сборку на новый Apple Silicon Runner либо поддерживает несколько приложений с разными требованиями к SDK. Он также удобен разработчикам без собственного Mac и руководителям, которым нужны заранее определённые условия отката и ограничения доступа.

Последнее обновление: 31 июля 2026 года. Данные сверены с требованиями Apple к Xcode, заметками о выпуске Xcode 27, документацией GitHub Actions для self-hosted runners и официальным сообщением о публичном образе xcode-27.

Что изменилось к 31 июля 2026 года

Apple указывает, что Xcode 27 beta 4 требует Mac на Apple Silicon и macOS Tahoe 26.4 или новее. В той же таблице требований Xcode 26.6 указан как отдельная ветка для macOS Tahoe 26.2 и последующих версий Tahoe. Это позволяет строить параллельную схему без немедленного удаления стабильного окружения. Требования Apple к версиям Xcode и macOS подтверждают эти ограничения.

Xcode 27 beta включает Swift 6.4 и SDK для платформ Apple 27, однако сама Apple сохраняет для beta-версии список известных проблем. В Release Notes отдельно отмечены ситуации с задержкой вывода stdout и stderr при параллельном тестировании, а также возможные проблемы с отображением устройств Simulator после установки. Поэтому результат одной успешной компиляции ещё не означает готовность к production-переключению. Release Notes Xcode 27 beta нужно проверять перед каждой волной миграции.

GitHub уже предоставил образ xcode-27 в публичном предварительном доступе для GitHub-hosted runners. Он доступен только на macOS Runner с архитектурой ARM64; Intel-вариант для этого образа не поддерживается. Это полезно как внешний контрольный запуск, но не заменяет отдельный self-hosted Runner, если команде нужны собственные сертификаты, фиксированные кеши, доступ по SSH или постоянное окружение. Официальное сообщение GitHub об образе Xcode 27 описывает текущий статус и поддерживаемые метки.

Решение до начала работ

Шаг 1. Зафиксируйте границы нового окружения

До загрузки Runner нужно описать, какие задания вообще имеют право попасть на Xcode 27. На первой неделе это должны быть отдельная ветка, ручной запуск workflow или тестовый pull request из доверенного репозитория. Production-релизы, ночные обязательные сборки и публикация в App Store должны продолжать использовать стабильную метку Xcode 26.6.

Главная ошибка на этом этапе — считать новый Runner просто более свежей копией старого. На практике в его состоянии могут отличаться:

• путь к Xcode и выбранный xcode-select;
• версия Swift-компилятора и набор SDK;
• установленные устройства Simulator;
• кеши Swift Package Manager, CocoaPods или других зависимостей;
• сертификаты, provisioning profiles и доступ к связке ключей;
• архитектура процесса, особенно при вызове Intel-зависимых инструментов через совместимый слой;
• права пользователя, SSH-ключи и доступ к внутренним сервисам.

Сначала сохраните текущие значения в артефакт или лог production-сборки. Минимальный снимок окружения должен выводить версию Xcode, Swift, SDK и архитектуру:

xcodebuild -version
swift --version
xcrun --sdk iphoneos --show-sdk-version
uname -m
xcode-select -p

Для Xcode 27 ожидается Apple Silicon, но проверять нужно фактическое значение uname -m, а не название модели в панели управления. Если вывод не соответствует ожидаемой архитектуре, задача должна завершаться до компиляции.

Какие macOS и чип нужны для Xcode 27 Runner?
Нужен Apple Silicon Mac с macOS Tahoe 26.4 или новее. Это не рекомендация «для лучшей производительности», а условие установки Xcode 27 beta 4, прямо указанное Apple. Если узел не проходит это требование, используйте его для Xcode 26.6 либо замените окружение. Таблица системных требований Apple должна быть повторно проверена после выхода следующей beta-версии.

Перед регистрацией также проверьте свободное место под Xcode, SDK, Simulator, временные файлы и кеши. Точное значение зависит от состава проекта и установленных платформ, поэтому универсальное число без измерения конкретного окружения было бы ненадёжным. Важнее заранее установить правило: если свободное место регулярно уменьшается после нескольких сборок, кеши нужно отделить от исходного рабочего каталога и включить контролируемую очистку.

Шаг 2. Подготовьте Apple Silicon Mac и доступ администратора

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

Не стоит регистрировать Runner под личным профилем разработчика, если узел будет обслуживаться командой. Лучше выделить отдельного системного пользователя, ограничить его доступ к проектам и не хранить в домашнем каталоге лишние приватные ключи. Администратор нужен для установки системного сервиса и подготовки окружения, но workflow не должен без необходимости выполняться от имени администратора.

Проверьте следующие пункты:

• [ ] Mac использует Apple Silicon, а не Intel.
• [ ] Установлена macOS Tahoe 26.4 или более новая версия.
• [ ] Xcode 27 beta установлен в отдельный каталог или имеет однозначное имя.
• [ ] Xcode 26.6 остаётся доступным на стабильном Runner.
• [ ] SSH-вход работает без интерактивного запроса пароля в автоматизированном сценарии.
• [ ] У технического пользователя есть доступ только к нужным рабочим каталогам.
• [ ] Mac не уходит в сон во время запланированного окна сборки.
• [ ] Определены допустимые репозитории, ветки и типы workflow.
• [ ] Сертификаты и provisioning profiles не копируются из production автоматически.

Шаг 3. Зарегистрируйте Runner и сделайте его различимым

Self-hosted Runner можно добавить на уровне репозитория, организации или предприятия. GitHub выдаёт временный регистрационный токен, поэтому его нельзя заранее зашивать в скрипты или хранить в репозитории. Официальная процедура включает загрузку приложения Runner, запуск config.sh и регистрацию узла по адресу репозитория или организации. Инструкция GitHub по добавлению self-hosted Runner описывает актуальный порядок действий.

После распаковки приложения на Mac схема выглядит так:

mkdir -p ~/actions-runner-xcode27
cd ~/actions-runner-xcode27

# Загрузка архива Runner выполняется по ссылке,
# которую GitHub показывает в настройках Runner.
tar -xzf actions-runner.tar.gz

./config.sh \
  --url https://github.com/ORG/REPO \
  --token REGISTRATION_TOKEN \
  --name macos-xcode27-validation \
  --labels self-hosted,macos,arm64,xcode-27,validation

Команду нужно адаптировать под конкретный репозиторий или организацию. Название macos-xcode27-validation является примером, а не обязательным значением. Важно, чтобы из него сразу было видно назначение узла.

Метки должны отражать не только операционную систему, но и смысл окружения: arm64, xcode-27, validation. GitHub сопоставляет runs-on с метками Runner; если подходящий онлайн-узел не найден, job остаётся в очереди. Документация GitHub по меткам self-hosted runners подтверждает, что пользовательские labels предназначены именно для маршрутизации заданий.

На уровне организации желательно создать отдельную группу, например ios-xcode27-validation, и разрешить ей доступ только к тестовым репозиториям или выбранным workflow. Runner Group создаёт дополнительную границу доступа между проектами. Документация GitHub по группам Runner описывает ограничения по организациям, репозиториям и workflow.

Шаг 4. Включите автоматический запуск после перезагрузки

Ручной запуск через ./run.sh годится только для первого теста. Для постоянно доступного узла приложение Runner следует установить как системный сервис. GitHub указывает, что на macOS после регистрации можно использовать сервисный сценарий Runner; доступны операции установки, запуска, остановки и проверки состояния. Инструкция GitHub по запуску Runner как сервиса содержит актуальные команды.

В каталоге Runner выполните:

cd ~/actions-runner-xcode27

./svc.sh install
./svc.sh start
./svc.sh status

Если команда установки требует административного подтверждения, используйте учётные данные администратора только в терминале, не помещая их в workflow. После перезагрузки Mac снова проверьте:

./svc.sh status

Затем откройте настройки Actions в GitHub и убедитесь, что Runner имеет статус Idle или Online, а не просто присутствует в списке. Минимальная проверка должна запускаться на нужной метке:

name: Проверка Xcode 27

on:
  workflow_dispatch:

jobs:
  toolchain:
    runs-on: [self-hosted, macos, arm64, xcode-27, validation]
    steps:
      - name: Версии среды
        run: |
          xcodebuild -version
          swift --version
          xcrun --sdk iphoneos --show-sdk-version
          uname -m

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

Шаг 5. Разведите Xcode 26.6 и Xcode 27 в одном workflow

Самый безопасный вариант — не пытаться переключать две версии на одном физическом узле в первом этапе. Production job продолжает использовать стабильную метку, а validation job — отдельную:

jobs:
  production:
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: [self-hosted, macos, arm64, xcode-26-6, production]
    steps:
      - uses: actions/checkout@v4
      - name: Стабильный toolchain
        run: |
          sudo xcode-select -s /Applications/Xcode_26.6.app
          xcodebuild -version
          xcodebuild archive \
            -scheme App \
            -archivePath build/App.xcarchive

  validation:
    if: github.event_name == 'workflow_dispatch' || github.ref != 'refs/heads/main'
    runs-on: [self-hosted, macos, arm64, xcode-27, validation]
    steps:
      - uses: actions/checkout@v4
      - name: Новый toolchain
        run: |
          sudo xcode-select -s /Applications/Xcode_27_beta.app
          xcodebuild -version
          xcodebuild build \
            -scheme App \
            -destination 'generic/platform=iOS'

Если у пользователя нет прав менять глобальный выбор Xcode, путь можно задавать через DEVELOPER_DIR для конкретной команды:

export DEVELOPER_DIR="/Applications/Xcode_27_beta.app/Contents/Developer"
xcodebuild -version

Главное — выводить фактическую версию в начало каждого job. Название workflow или Runner не является доказательством, что команда действительно использовала нужный SDK.

Как одновременно сохранить Xcode 26.6 и Xcode 27?
Наиболее предсказуемо — держать их на разных Runner и маршрутизировать job по меткам. Установка двух приложений на одном Mac возможна, но тогда нужно отдельно контролировать DEVELOPER_DIR, Simulator, кеши и права доступа; ошибка в одном глобальном xcode-select способна изменить поведение соседнего job.

Шаг 6. Проведите приёмку в течение первого дня

Первый день миграции должен проверять не «зелёный статус» одного workflow, а полный путь от зависимостей до подписанного архива. Для каждого этапа фиксируйте входные условия, команду, результат и следующий шаг при ошибке.

Рекомендуемый порядок:

1. Клонирование репозитория в чистый рабочий каталог.
2. Установка Swift Package Manager, CocoaPods или других зависимостей.
3. Проверка версии Xcode, Swift, SDK и архитектуры.
4. Обычная компиляция приложения.
5. Запуск unit-тестов.
6. Запуск UI-тестов на заранее подготовленном Simulator.
7. Создание Archive.
8. Проверка подписи и профиля распространения.
9. Сохранение лога, архива и диагностических файлов.
10. Повторный запуск после очистки выбранных кешей.

Если ошибка появилась только на Xcode 27, сравните её с Release Notes Xcode 27, затем повторите тот же job на Xcode 26.6. Такой контроль не доказывает автоматически, что виновата beta, но помогает разделить четыре класса причин: код проекта, сторонняя зависимость, конфигурация Runner или известная проблема Xcode.

На этом этапе не следует публиковать тестовый архив как production-релиз. Артефакт нужен для сравнения, проверки подписи и анализа различий между двумя линиями.

Шаг 7. Защитите Runner и подготовьте быстрый откат

Self-hosted Runner — это не одноразовая чистая виртуальная машина. GitHub прямо предупреждает, что непроверенный код workflow может получить доступ к окружению, секретам и сетевым ресурсам. Особенно рискованны публичные репозитории, где сторонние pull request способны запускать код на вашем Runner. Рекомендации GitHub по безопасному использованию self-hosted runners рекомендуют ограничивать такие Runner приватными репозиториями и разделять доступ группами.

Практическая схема изоляции выглядит так:

• разрешите группе xcode27-validation только выбранные репозитории;
• не подключайте к beta-Runner production-сертификаты без необходимости;
• ограничьте доступ к SSH-ключам и внутренним API;
• запретите запуск произвольных workflow из внешних fork;
• разделите кеши Xcode 26.6 и Xcode 27;
• сохраняйте логи и артефакты в разных пространствах;
• не используйте один рабочий каталог для параллельных job;
• удаляйте временные профили и ключи после завершения тестового процесса;
• назначьте владельца, который отвечает за обновление beta и удаление старой регистрации.

Как изолировать сертификаты и права репозиториев?
Распределяйте доступ на двух уровнях: Runner Group определяет, какие репозитории и workflow могут назначать узел, а secrets и signing assets должны быть доступны только конкретному окружению. Секрет, присутствующий на машине, следует считать потенциально доступным любому workflow, который реально получил выполнение на этом Runner.

Что делать, если Xcode 27 beta ломает сборку?
Не переустанавливайте production-ноду в спешке. Сначала отключите validation job или уберите проблемную ветку с метки xcode-27, затем повторно запустите тот же commit на Runner Xcode 26.6. Если стабильная линия проходит, зафиксируйте ошибку в журнале миграции, сохраните лог beta и отложите расширение трафика до выхода исправления либо подтверждения совместимого обходного решения.

К концу первой недели должны быть определены конкретные условия отката:

• две последовательные ошибки Archive на одном проекте;
• невозможность проверить подпись тестового артефакта;
• непредсказуемое поведение Simulator;
• недоступность Runner после перезагрузки;
• загрязнение кеша или пересечение сертификатов;
• ошибка, влияющая на релизную ветку;
• отсутствие понятного объяснения после сверки с Release Notes.

Полный переход оправдан только тогда, когда эти условия не срабатывают на нескольких типах заданий, а команда может вернуть production job на Xcode 26.6 без редактирования исходного кода.

Когда удалённый Mac рациональнее собственной машины

Для двойной миграции нужен не просто Mac, на котором однажды запускается Xcode. Нужен узел, который можно оставить онлайн, подключить по SSH, перезагрузить после обновления и обслуживать без присутствия разработчика. Если локальный Mac используется для работы, уходит в сон, занят другими задачами или не подходит по Apple Silicon, он становится слабым местом CI/CD.

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

Текущая схема на локальном или случайно выделенном Mac часто имеет три недостатка: она привязывает CI к рабочему устройству, не гарантирует круглосуточную доступность и смешивает production-секреты с экспериментальным инструментарием. Отдельный Mac в Vuncloud позволяет вынести Xcode 27 в самостоятельный контур, сохранить root-доступ и сначала прогнать непроизводственную ветку, не меняя стабильный Runner. Для команды, которой требуется только временная beta-проверка или отдельный узел на период миграции, это обычно безопаснее, чем покупать машину ради одного переходного этапа.

Начните не с переключения runs-on, а с чек-листа: отдельный Apple Silicon Mac, изолированный Runner Group, два набора меток, раздельные кеши, тестовая подпись и подтверждённый сценарий отката. После этого Xcode 27 можно расширять от ручного запуска к ограниченной ветке и только затем рассматривать как основной инструмент.