GitHub Actions macOS 26 Runner: выбрать arm64 или Intel? 2026

Сборка на macos-26 прошла, но это ещё не доказывает совместимость с Intel — или наоборот.

Быстрый выбор: для нового проекта и обычной сборки под Apple Silicon сначала проверьте macos-26; выбирайте macos-26-intel, только если нужно проверить поведение, зависимость или результат именно на Intel. Если проект обязан поддерживать обе архитектуры, разделите проверки по заданиям.

Материал для независимых разработчиков, которым нужно выбрать Runner для повседневной сборки iOS или macOS.
Для Apple-платформенных команд, которые уточняют требования к Intel и устаревшим зависимостям.
Для CI- и платформенных инженеров, которым нужно утвердить метки, матрицу и правила для исключений.

Последнее обновление: 2 ноября 2026 года. Сверено с объявлением GitHub о доступности macOS 26, документацией о выборе Runner и объявлением образа Xcode 27. Перед публикацией проверьте, что метки и образы по-прежнему доступны.

SECTION 01Как читать метки, не смешивая архитектуру Runner и архитектуру продукта

По документации GitHub, для macOS 26 доступны метки macos-26 и macos-26-intel: первая соответствует хосту arm64, вторая — хосту Intel. Эти значения определяют, где запустится задание, но не задают автоматически архитектуру выпускаемого приложения. Сверьте соответствие меток с документацией GitHub по выбору Runner и актуальным списком образов и их возможностей.

Для выбора важно разделять четыре вещи:

• Архитектура хоста — процессор машины, выполняющей job.
• Целевая архитектура — платформа, для которой настроена сборка.
• Содержимое артефакта — например, бинарный файл только для одной архитектуры или универсальный macOS-бинарник.
• Покрытие тестами — какие среды и варианты поведения фактически проверяет workflow.

Apple описывает создание универсального macOS-бинарника как отдельную задачу сборки. Поэтому наличие нескольких архитектур в одном артефакте не означает, что его поведение проверено на каждой из них: изучите руководство Apple по универсальным бинарным файлам. Аналогично, сборка на arm64 не доказывает, что Intel-специфичная ошибка воспроизведена или устранена.

Эта разница часто теряется в CI: команда видит зелёную сборку и трактует её как полную проверку совместимости, хотя job мог выполнить только компиляцию на одной архитектуре. В результате ограничение обнаруживается позже — при запуске у пользователя, на тестовой машине или в отдельном release-процессе.

SECTION 02Независимому разработчику: с чего начать проверку

Если вы поддерживаете один основной путь сборки и не обязаны отдельно принимать Intel-совместимость, начните с macos-26. Это стартовая гипотеза для проверки, а не утверждение, что любой скрипт, пакет или сторонний Action уже работает в arm64-среде.

Пройдите короткий тест на текущем workflow:

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

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

Для Xcode 27 проверьте не только версию инструмента в образе, но и доступность нужной конфигурации для выбранной метки. GitHub объявил о доступности образа Xcode 27 отдельно; посмотрите объявление о выпуске образа и примечания Apple к выпуску Xcode 27. Требования к системе и инструментам сверяйте также с официальной страницей системных требований Xcode. Не переносите вывод о наличии Xcode на одном образе на все метки автоматически.

SECTION 03Команде Apple Silicon: проверьте всю цепочку, а не только компилятор

Для команды, у которой основной целевой путь связан с Apple Silicon, arm64 может быть разумным вариантом по умолчанию, если его поддерживает вся цепочка. Под «цепочкой» подразумеваются не только Xcode и компилятор, но и сторонние библиотеки, инструменты генерации, скрипты подготовки, расширения сборки, тестовые утилиты и Actions.

Зафиксируйте в протоколе пробного запуска:

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

Если инструмент сообщает об ошибке архитектуры, не подменяйте диагностику общей фразой «Xcode не работает на arm64». Сначала определите, какой именно процесс или бинарный компонент не удалось запустить. Apple отдельно документирует некоторые ошибки сборки для Apple Silicon и способы их разбирать в технической заметке TN3117. Это помогает отличить архитектурное несоответствие зависимости от ошибки параметров компиляции или конфигурации проекта.

Для команды есть и обратная сторона: если arm64 прошёл локально, это не заменяет CI-проверку на GitHub-hosted Runner. Рабочая станция и образ CI могут отличаться установленными инструментами, переменными, разрешениями и способом получения зависимостей. Принимайте решение по выполнению проекта на выбранной метке, а не по совпадению названий архитектуры.

SECTION 04Команде с поддержкой Intel: разделите сборку и приёмку

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

Таблица — не обещание, что любая комбинация доступна для каждого репозитория или типа Runner. Проверьте конкретные метки и ограничения GitHub перед включением заданий. Для более крупных Runner GitHub публикует отдельные условия и ограничения; изучите официальную документацию о larger runners, если рассматриваете такой вариант.

Сценарий: проект собирает приложение для нескольких платформ, а проблема проявляется только при использовании старой Intel-зависимости. Вместо перевода всего CI на Intel выделите эту проверку в отдельную job, сохраните основной arm64-путь и добавьте журнал версий зависимостей. Так обычная сборка не наследует ограничение одного устаревшего компонента, а исключение остаётся видимым и проверяемым.

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

SECTION 05Команде с устаревшими зависимостями: сначала найдите источник ограничения

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

Практическая проверка выглядит так:

1. Найдите в workflow команды установки, генерации кода, компиляции и запуска тестов.
2. Для каждого скачиваемого бинарника установите архитектуру и источник, используя доступные метаданные и документацию поставщика.
3. Запустите проект на macos-26 и сохраните точную ошибку вместе с шагом workflow.
4. Повторите только затронутую job на macos-26-intel, если гипотеза о зависимости подтверждается.
5. Сравните не только статус job, но и полученный артефакт, тестовые результаты и содержимое журналов.
6. Запишите владельца исключения и условие, при котором его нужно пересмотреть.

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

Сторонний Action тоже нужно оценивать по фактическому поведению. Уточните, запускает ли он локальный бинарный инструмент, загружает ли отдельный компонент и можно ли заменить его поддерживаемой версией. Наличие Action в workflow не подтверждает совместимость с обеими архитектурами; проверяйте исходный код и инструкции конкретного Action, а затем подтверждайте результат в job.

SECTION 06Команде подписи и выпуска: разделите ограничения на три категории

Проблемы с публикацией часто ошибочно приписывают архитектуре Runner. Разнесите проверки по отдельным категориям: кодовая подпись и доступ к секретам; регистрация тестовых устройств и требования выпуска; архитектура хоста и поведение инструментов. Только после этого определяйте, влияет ли macos-26 или macos-26-intel на конкретный шаг.

Для каждой release-job задайте вопросы: какой сертификат и профиль используются, кто имеет доступ к секретам, какой продукт подписывается, зависит ли шаг от физического устройства или его регистрации, и какое поведение хоста требуется подтвердить. Затем выполните проверку на выбранной метке, не обобщая единичный результат на все hosted Runner.

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

SECTION 07CI-руководителю: закрепите решение условными правилами

Используйте список условий, чтобы выбрать базовую схему и не расширять исключения без причины:

• Если проект новый, основной путь рассчитан на Apple Silicon, а обязательные зависимости и Actions прошли пробную проверку, выберите macos-26 для обычной сборки; в противном случае сначала изолируйте несовместимый шаг.
• Если вы обязаны проверять поведение на Intel, воспроизводить Intel-специфичный дефект или использовать подтверждённую Intel-зависимость, выделите для этого macos-26-intel; иначе не переводите на Intel остальные задания.
• Если заявлена поддержка обеих архитектур, создайте матрицу с отдельными результатами сборки и тестов для нужных меток; если требование касается только состава бинарника, отдельно проверьте, достаточно ли сборки артефакта без запуска полного набора на каждом хосте.
• Если причина использования Intel перестала воспроизводиться после обновления зависимости, повторно проверьте arm64 и закройте исключение, а не оставляйте его без владельца.
• Если job требует постоянного состояния, управляемого окружения или отдельного режима обслуживания, сравните hosted Runner с выделенным удалённым Mac; если задача эпизодическая и полностью описана workflow, сначала оставайтесь на GitHub-hosted Runner.

Укажите владельца каждой исключительной job, основание архитектурного требования, артефакт доказательства и событие для пересмотра — например, обновление критической зависимости. Это предотвращает ситуацию, в которой Intel остаётся по инерции, хотя проект уже не использует ограниченный компонент.

Для практического испытания удалённой среды можно начать с описания удалённого Mac для разработки и CI. Если после проверки вам нужен отдельный управляемый Mac, сравните условия на странице вариантов аренды Mac и проверьте актуальные тарифы MACNOX; не переносите свойства такого окружения на GitHub-hosted Runner.

SECTION 08FAQ: частые решения по macOS 26

Вопросы ниже помогают закрепить выбор, но не заменяют проверку актуальных образов GitHub: состав образа и доступность метки следует сверять непосредственно перед изменением workflow.

Что означают метки macos-26 и macos-26-intel?
Они выбирают архитектуру хоста задания: соответственно arm64 и Intel. Это не синоним архитектуры конечного приложения. Перед изменением конфигурации проверьте соответствие меток по документации Runner и отдельно проверьте, что именно собирает ваш проект.

Что выбрать для обычной CI-сборки iOS?
Если обязательные инструменты и зависимости прошли реальную проверку в arm64-среде, начните с macos-26. Затем проверьте тесты, подпись и артефакт. Если вам нужно подтвердить поведение именно на Intel, добавьте отдельную job, а не делайте вывод по успешной компиляции на arm64.

Когда оправдан macos-26-intel?
Когда есть подтверждённое требование к Intel-хосту: тест, который воспроизводит архитектурный дефект, зависимость с соответствующим ограничением или обязательная проверка поведения для Intel-пользователей. Запишите причину и владельца задания. Не используйте метку только потому, что старый workflow уже был настроен таким образом.

Как проверить образ с Xcode 27?
Сверьте объявление GitHub о доступности образа, требования Apple и состав инструментов для конкретной метки. Затем выполните реальные команды проекта и проверьте полученный продукт. Сам факт, что workflow запускает Xcode, не подтверждает поддержку всех зависимостей, корректность тестов или Intel-совместимость приложения.

Для большинства новых проектов правильный первый шаг — небольшой запуск на arm64 и проверка полного результата, а не миграция всех заданий на Intel. Intel имеет смысл там, где его требует подтверждённый тест, зависимость или обязательство по совместимости. Если же вашему процессу нужен не просто Runner для отдельной job, а постоянно доступная управляемая Mac-среда, аренда MACNOX может быть уместнее hosted Runner; для разовых воспроизводимых заданий сохраняйте GitHub Actions и не добавляйте отдельную инфраструктуру без операционной причины.

SECTION 09Часто задаваемые вопросы

SECTION 10Дополнительные материалы

• Приёмка GitHub Actions с Xcode 27: проверка ARM64, подписи и отката
• Как выявить Intel-зависимости и проверить переход на Apple Silicon
• Эластичный пул Mac Runner: когда масштабирование подходит для CI