Как принять миграцию Rosetta в macOS 27? Чек-лист CI 2026

На 20 сентября 2026 года Apple указывает, что macOS 27, выпущенная 14 сентября 2026 года, стала последним большим выпуском с общей поддержкой Rosetta для обычных Intel-приложений — это подтверждено в сообщении Apple о доступности новых программных платформ. Поэтому миграцию Rosetta в macOS 27 нельзя откладывать до полного исчезновения поддержки: уже сейчас перенесите сборку на изолированный Apple Silicon-узел, найдите все вызовы x86_64 и примите arm64-сборку, тесты, подпись и перезапуск как единый критерий.

Симптом: приложение показывает Universal Binary, но генератор кода, плагин или процесс CI всё ещё запускается как x86_64.

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

Кому нужен этот runbook

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

Он также нужен DevOps-инженерам, обслуживающим удалённый Mac CI, и ответственным за релиз, которым требуется одновременно вести Apple Silicon как основную линию и Intel-совместимую линию для оставшихся пользователей.

**Предупреждение:** macOS 27 ещё может запускать отдельные Intel-only приложения. Это не доказывает, что ваш проект готов к миграции: запуск через Rosetta способен скрыть отсутствие arm64-среза, неверный PATH и старую зависимость в Build Phase.

Граница совместимости macOS 27

Текущее утверждение Apple нельзя трактовать как немедленное отключение всех Intel-программ. Речь идёт о последнем большом выпуске с общей поддержкой Rosetta; Apple отдельно описывает ограниченные будущие сценарии для некоторых старых игр. Поведение конкретного приложения всё равно определяется его бинарниками, загрузчиками, динамическими библиотеками, JIT-кодом и процессными плагинами. Проверяйте эту границу по документации Apple о среде перевода Rosetta, а не по одному успешному старту.

Разделяйте четыре понятия:

• Intel Mac — физический компьютер с архитектурой x86_64;
• Apple Silicon — Mac с arm64-процессором;
• Rosetta — слой перевода, позволяющий Apple Silicon запускать часть Intel-кода;
• Universal Binary — отдельный артефакт с несколькими архитектурными срезами.

Universal Binary не гарантирует нативность всей цепочки. Главный executable может содержать arm64 и x86_64, тогда как подключаемый плагин или генератор схем остаётся только Intel. В таком случае пользовательский интерфейс может открыться, но сборка, экспорт проекта или конкретная функция завершится отказом.

Инвентаризация исполняемой цепочки

Начинайте не с Xcode-проекта, а с полного списка того, что реально запускается. Включите приложение, расширения, плагины, Framework, динамические и статические библиотеки, командные инструменты, daemon-процессы, генераторы кода, скрипты и программы, вызываемые пользовательскими Build Phase.

Для каждого объекта заведите запись со следующими полями:

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

Проверяйте файлы непосредственно на узле:

file "/path/to/artifact"
lipo -info "/path/to/universal-binary"

file помогает увидеть, является ли объект arm64, x86_64 или универсальным. lipo -info показывает доступные срезы у Mach-O-артефакта. Команды не заменяют запуск: бинарник может иметь arm64-срез, но обращаться к Intel-only плагину при выполнении.

Отдельно просмотрите:

find "/path/to/repository" -type f -perm -111 -print
grep -R "x86_64\|arch -x86_64\|/usr/local" "/path/to/repository"

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

<

Объект	Что проверить	Доказательство	Решение
Главное приложение и расширения	Наличие arm64-среза	file, архив сборки	Пересборка или блокировка релиза
Framework и XCFramework	Срез целевой платформы	lipo -info, содержимое пакета	Обновить, пересобрать или заменить
Плагины и генераторы	Архитектура фактического процесса	журнал CI, сведения о процессе	Перевести на arm64 или вынести
Командные инструменты	Реальный файл из PATH	command -v, file	Исправить PATH и установку
Статические библиотеки	Совместимость на этапе линковки	лог linker	Получить arm64-вариант
Daemon и помощники	Запуск после перезагрузки	журнал старта и процесс	Пересобрать, заменить или исключить

Не помечайте задачу как закрытую только потому, что основное приложение стало Universal Binary. Закрытие возможно, когда вся обязательная цепочка либо имеет arm64, либо сознательно исключена из нативного production-пути с отдельным владельцем и сроком пересмотра.

Инструменты сборки и различия сеансов

Скрытая проблема часто находится не в исходниках, а в окружении. На локальном Mac терминал может использовать нативный Homebrew, а SSH-сеанс — другой PATH. Учётная запись Runner может вообще не загружать пользовательский профиль и вызывать старую Intel-утилиту из заранее сохранённого каталога.

Сравните результаты в трёх режимах:

uname -m
arch
command -v xcodebuild
command -v swift
command -v <generator>
file "$(command -v <generator>)"

Подставьте вместо <generator> фактическое имя генератора проекта или кода. Выполните команды в интерактивном терминале, через SSH и внутри CI job. В каждом журнале сохраняйте PATH, HOME, текущий каталог, версию Xcode и архитектуру найденных файлов.

Затем проверьте скрипты:

• нет ли arch -x86_64;
• не вызывается ли shell-программа из Intel-каталога;
• не устанавливает ли Build Phase инструмент из локального пользовательского пути;
• не отличается ли переменная PATH у Runner от SSH-сеанса;
• не запускается ли кодогенератор только после включения Rosetta.

Критерий прохождения здесь строгий: новый пользователь или чистый узел должен завершать сборку без предварительной установки Rosetta и без ручной подмены PATH. Если старое окружение «случайно» помогает, это не миграция, а зависимость, которую нужно устранить.

Сторонние бинарники и границы замены

Разделите каждую Intel-зависимость на четыре класса:

• можно обновить до версии с arm64;
• можно пересобрать из исходников;
• можно заменить другим инструментом;
• пока нельзя перенести без потери функции.

Для первого класса зафиксируйте минимальную версию и повторите проверку после скачивания. Для второго сохраните параметры сборки и источник. Для закрытого инструмента запросите у поставщика Universal Binary или arm64-поставку; временный запуск через Rosetta не должен считаться постоянным решением.

Особое внимание уделите XCFramework: наличие каталога не означает наличие нужного среза для каждой платформы. Проверьте именно вариант, который выбирает ваш target, а не только общий список файлов. Для плагинов внутри процесса риск выше: приложение может быть нативным, но загрузка несовместимого модуля завершит тест или рабочий сценарий.

<

Результат проверки	Статус	Допустимое действие
Все обязательные компоненты запускаются arm64	Проходит	Допустить в основную линию
Intel-компонент заменяем, но замена не подтверждена	Условно	Оставить блокер до повторного теста
Компонент можно запускать отдельно	Ограниченно	Вынести в отдельную совместимую задачу
Компонент загружается внутри arm64-процесса и не имеет arm64	Стоп	Не принимать production-узел
Архитектура неизвестна из-за старого кэша	Стоп	Очистить кэш и повторить проверку

Запрещённый обход — надолго исключить arm64, принудительно запускать весь job как x86_64 или считать перевод всей машины достаточной проверкой. Такие действия скрывают отсутствие среза и не дают доказательства, что будущая нативная линия будет работать.

Тесты, подпись и чистый повтор

Разделите проверку на нативную и совместимую. В нативной ветке запускайте приложение, unit-тесты, интеграционные тесты, загрузку плагинов и ключевые бизнес-задачи именно на Apple Silicon без принудительного arch -x86_64.

Если вы продолжаете поставлять Intel-версию, отдельная ветка должна проверять x86_64-срез или Universal Binary на соответствующем сценарии. Успешный тест arm64 на Apple Silicon не подтверждает поведение Intel-пользователя. И наоборот, успешная транслируемая проверка не подтверждает нативную загрузку.

Для проектов с JIT, низкоуровневыми инструкциями или процессными модулями добавьте отдельные тесты. В доказательства сохраняйте:

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

Официальные параметры архитектуры сборки сверяйте с [Xcode Build Settings Reference](https://developer.apple.com/documentation/xcode/build-settings-reference?changes=_1). После сборки повторите подпись, нотариальную проверку и публикацию под тем же исполнителем, который используется в production. Проверьте Keychain: миграция может пройти до этапа компиляции, но остановиться на сертификате, профиле или доступе к секрету.

Кэш, Runner и удалённый Mac CI

Перевод удалённого Mac CI с Intel-инструментов на arm64 начинайте с отдельного узла. Не меняйте существующий production Runner до того, как получите воспроизводимый результат на чистой машине.

Последовательность действий:

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

Проверьте ключи кэша. Если в них нет архитектуры, версии инструмента или целевой платформы, arm64-job способен получить старый x86_64-артефакт. Ошибка может проявиться только на линковке или при запуске теста, поэтому «кэш найден» не является положительным результатом.

Также ищите условия вроде uname, arch, x86_64, старые URL загрузки и ветви, зависящие от имени узла. В заметках к выпуску macOS 27 проверяйте изменения, которые могут влиять на инструменты, подпись и выполнение CI. Перед публикацией повторите проверку после перезагрузки: сервис Runner, SSH-доступ, Keychain, фоновые процессы и сетевые разрешения должны восстановиться без ручного запуска.

Чек-лист приёмки и решение о переключении

Отметьте пункт только после получения лога или файла-доказательства:

• [ ] Создана полная карта приложения, расширений, Framework, библиотек, плагинов и вспомогательных программ.
• [ ] Для каждого Mach-O-объекта зафиксирован результат file или lipo -info.
• [ ] Интерактивный терминал, SSH и учётная запись Runner используют ожидаемый PATH.
• [ ] В CI нет несанкционированного arch -x86_64 и скрытого запуска Intel-инструмента.
• [ ] Все обязательные сторонние зависимости обновлены, пересобраны, заменены или оформлены как явный блокер.
• [ ] Чистая сборка на Apple Silicon проходит без Rosetta.
• [ ] Нативно выполнены запуск, unit-тесты, интеграционные тесты и загрузка плагинов.
• [ ] Удалены воспроизводимые кэши, выполнено чистое клонирование и повторена сборка.
• [ ] Подпись, Keychain, нотариальная проверка и публикация прошли под production-исполнителем.
• [ ] После перезагрузки узла Runner и ключевые задания восстановились.
• [ ] Intel-совместимая линия отделена от основной и имеет собственный критерий завершения.
• [ ] Для каждого оставшегося Intel-компонента назначены владелец и условие выхода.

Решение принимайте по трём классам. **Проходит** — arm64 является основной производственной цепочкой, доказательства собраны, а Intel-линия ограничена совместимым артефактом. **Ограниченное принятие** — нативная сборка готова, но отдельная зависимость остаётся вне production-пути с конкретным владельцем. **Блокировка** — сборка зависит от Rosetta, неизвестного кэша, неподтверждённого плагина или ручного состояния узла.

FAQ для миграции

Сможет ли macOS 27 запускать приложения только для Intel?

Да, текущая граница не означает немедленный запрет всех Intel-приложений. Apple указывает, что macOS 27 — последний большой выпуск с общей поддержкой Rosetta для обычных Intel-приложений; для конкретной программы результат зависит от бинарника, библиотек, плагинов и поведения во время выполнения. Поэтому совместимость подтверждается тестом, а не только запуском приложения.

Как понять, что инструмент CI работает через Rosetta?

Сравните архитектуру самого процесса и исполняемого файла в интерактивном терминале, SSH-сеансе и под учётной записью Runner. Используйте file, arch и сведения о процессах, затем повторите сборку на чистом Apple Silicon-узле. Если arm64-узел вызывает x86_64-утилиту, оставлять такую цепочку в качестве основной производственной линии нельзя.

Как найти бинарные зависимости x86_64 в проекте?

Составьте перечень приложений, Framework, XCFramework, плагинов, динамических и статических библиотек, командных утилит и генераторов кода. Для каждого файла выполните file, а для универсальных артефактов дополнительно lipo -info. Зафиксируйте архитектуру, источник, место вызова, владельца исправления и условие закрытия блокера.

Означает ли Universal Binary, что Rosetta больше не нужна?

Нет. Universal Binary описывает конкретный артефакт, в котором присутствуют несколько архитектурных срезов, но рядом могут оставаться Intel-only плагины, генераторы, скрипты или закрытые вспомогательные программы. Нативный запуск подтверждается только после проверки всей цепочки процесса и выполнения тестов именно в arm64-режиме.

Как перевести удалённый Mac CI с Intel-инструментов на arm64?

Сначала изолируйте Apple Silicon-узел и воспроизведите там сборку с чистым клонированием и пустым воспроизводимым кэшем. Затем исправьте PATH, Runner, зависимости, скрипты, подпись и публикацию. Старую Intel-линию оставьте отдельной только для совместимого артефакта, а основную production-задачу переключайте после повторной проверки тем же коммитом.

Производственная граница и откат

Apple Silicon должен стать кандидатом на основную линию, но не обязан немедленно заменить весь процесс доставки. Если Intel-пользователи ещё поддерживаются, сохраните отдельный compatibility job, который отвечает только за нужный Intel- или Universal Binary-артефакт. Он не должен продолжать выполнять все production-сборки и маскировать проблемы основной цепочки.

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

Если имеющийся Intel Mac не позволяет проверить arm64-линейку, временно вынесите копию процесса на изолированный удалённый Apple Silicon Mac. Руководство по удалённому Mac для разработчиков поможет подготовить среду доступа, а варианты аренды Mac — оценить временный узел без немедленной покупки оборудования.

Текущий Intel Mac неудобен для этой задачи по трём причинам: он не показывает, как ведёт себя нативная arm64-сборка, сохраняет риск случайно проверять Rosetta-путь и привязывает CI к локальному состоянию машины. Полностью виртуальная или эмулированная схема добавляет ещё один слой неопределённости для плагинов, подписи и перезагрузки. В такой ситуации аренда Mac у MACGPU даёт более чистый способ воспроизвести pipeline на реальном Apple Silicon-узле с SSH, VNC или веб-доступом и затем решить, нужен ли вам постоянный узел, отдельная Intel-ветка или только временная среда миграции.

Проверяйте актуальные ограничения по документации Apple об Apple Silicon, особенно после обновлений macOS 27.x, Xcode и сторонних бинарных зависимостей. Дата повторной проверки этой статьи — 20 сентября 2026 года; исходные утверждения сверены с материалами Apple Developer, заметками к выпуску macOS и документацией Rosetta.