Rosetta 2: последняя поддержка macOS 27 — список миграции для исследований 2026

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

Быстрое решение: не отключайте старую среду сразу после выхода macOS 27; новые проекты переводите на arm64, текущие фиксируйте на проверенной macOS 27 и параллельно проверяйте на Apple Silicon плагины, библиотеки, лицензии и результаты. Если миграция не прошла, оставляйте двойной контур до выполнения заранее определённых условий остановки.

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

Последнее обновление: 15 сентября 2026 года. Даты и границы поддержки сверены с официальным сообщением Apple Developer о Rosetta, документацией Rosetta и записью о выпуске macOS 27.

SECTION 01 Что именно заканчивается после macOS 27

macOS 27.0 выпущена 14 сентября 2026 года и является последней основной версией с общей поддержкой Rosetta 2. Начиная с macOS 28, Intel-only приложения больше не получают универсальную поддержку Rosetta; сохраняется только ограниченная функция для отдельных старых игр. Это не означает, что все научные программы перестают запускаться на следующий день после установки macOS 27, но делает зависимость от трансляции временным техническим долгом, а не устойчивой стратегией.

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

Не смешивайте четыре разных случая:

• Intel-only Mac App — приложение целиком собрано для x86_64 и зависит от Rosetta 2.
• Universal App — в пакете есть варианты для arm64 и x86_64, но подключаемый модуль может оставаться Intel-only.
• Apple Silicon App — основной исполняемый файл рассчитан на arm64, однако внешняя команда или динамическая библиотека может запускаться через отдельный слой совместимости.
• Linux-бинарник внутри виртуальной машины — это другой путь трансляции и другая операционная среда; наличие Rosetta для macOS не доказывает совместимость Linux-инструмента.

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

SECTION 02 Как выбрать маршрут для своей группы

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

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

SECTION 03 Первый шаг: студентам нужно защитить ближайшую сдачу

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

Проверьте последовательно:

1. Запускается ли основное приложение без изменения режима совместимости.
2. Открывается ли файл, созданный в прежней версии.
3. Загружается ли назначенный преподавателем плагин.
4. Проходит ли проверка лицензии через требуемую сеть или локальный сервер.
5. Сохраняется ли результат в формате, который принимает курс.
6. Совпадают ли ключевые значения и визуальные элементы отчёта.
7. Повторяется ли весь путь от импорта до экспорта без ручной коррекции.

Если программа открывает проект, но меняет важную функцию или экспорт, такой тест считается неудачным. Успешный запуск окна — лишь проверка старта, а не доказательство совместимости научного результата.

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

SECTION 04 Второй шаг: диссертацию переводят через заморозку и двойную проверку

В активной статье или диссертации изменение окружения может повлиять не только на запуск, но и на численный результат. Зафиксируйте:

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

Исходные данные храните в режиме, исключающем случайную перезапись. Новую arm64-ветку запускайте на том же наборе данных, с теми же параметрами и тем же порядком экспорта. Сравнивайте журналы, контрольные значения, число обработанных объектов и критерий допуска, принятый в вашем проекте.

Не заменяйте производственную среду, пока не выполнены оба условия:

1. показательный анализ завершается без ручного обхода ошибки;
2. результаты совпадают в пределах заранее утверждённого допуска или различия объяснены и документированы.

Если нативная версия прошла только запуск, но не прошла воспроизводимость, оставляйте двойной контур. Один путь используется для завершения текущей работы, второй — для новых запусков и поиска замены. Такой подход лучше, чем бессрочное использование старой архитектуры без плана, и безопаснее, чем немедленное удаление проверенной среды.

SECTION 05 Как проверить Intel-зависимости в приложении, плагине и командной строке

В Finder откройте свойства приложения и проверьте поле архитектуры. Для более точной проверки используйте «Терминал»:

file "/Applications/Название.app/Contents/MacOS/Название"

Для универсального бинарника можно дополнительно выполнить:

lipo -info "/Applications/Название.app/Contents/MacOS/Название"

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

Для командной утилиты определите путь:

which имя-команды
file "$(which имя-команды)"

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

find "/путь/к/проекту" \( -name "*.dylib" -o -name "*.framework" -o -name "*.so" \) -print

Каждый найденный бинарный компонент проверяйте отдельно. Apple рекомендует строить универсальные macOS-бинарники, содержащие arm64 и x86_64-варианты; правила сборки описаны в руководстве по Universal Binary. Но наличие двух архитектур в главном файле не означает, что внешняя библиотека или плагин также универсальны.

Обратите внимание на следующие скрытые точки:

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

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

SECTION 06 Как лаборатории мигрировать с x86_64 на Apple Silicon

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

Процесс миграции можно организовать так:

1. Составьте перечень всех рабочих станций, проектов и владельцев, не удаляя старые записи после первой проверки.
2. Разделите компоненты на нативные arm64, Universal, Intel-only и неизвестные.
3. Выберите по одному представительному образцу для каждого класса задач.
4. Настройте изолированную Apple Silicon-среду с теми же файлами, параметрами и доступами.
5. Проверьте основной путь, импорт, экспорт, плагины, лицензирование и пакетную обработку.
6. Отдельно испытайте физические приборы и школьную или университетскую сетевую авторизацию на месте использования.
7. Зафиксируйте решение: мигрировать, заморозить macOS 27 или оставить двойной контур.
8. Назначьте дату повторной проверки для неизвестных компонентов и владельца, который отвечает за неё.

Запуск через удалённый Mac полезен для предварительной приёмки, когда нужно проверить обезличенный образец, не покупая отдельную машину для каждого участника. В справочном центре VPSNIX заранее проверьте порядок удалённого доступа, а перед заказом сверяйте условия в разделе тарифов аренды Mac. Однако удалённая проверка не заменяет тест на реальном месте, если рабочий процесс зависит от USB-прибора, локального ключа лицензии или закрытой университетской сети.

SECTION 07 Что должны проверить разработчики собственного научного ПО

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

Сначала соберите карту артефактов:

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

Затем проведите два независимых прогона: arm64 и x86_64. Второй нужен для переходного периода и проверки обратной совместимости, но не должен считаться долгосрочной целью. Рекомендации по переносу приложений и учёту архитектурных различий собраны в руководстве Apple по портированию macOS-приложений и документе об архитектурных различиях.

Проверяйте не только факт сборки, но и:

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

Публикуйте архитектуру каждого артефакта в документации релиза. Если один компонент пока нельзя собрать для arm64, укажите это явно, определите замену или ограничьте поддерживаемый сценарий. Не называйте программу нативной только потому, что её интерфейс запускается без сообщения Rosetta.

SECTION 08 Как принять итоговое решение руководителю проекта

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

Нативная миграция. Выбирайте её для новых проектов и для старых задач, где основное ПО, плагины, команды, лицензия и приборы прошли приёмку на arm64. После этого зафиксируйте версии и не возвращайте Intel-компоненты без записи в реестре.

Заморозка macOS 27. Она оправдана для завершаемой диссертации или курса с близкой сдачей, если текущая среда проверена, результаты уже получены, а миграция может изменить вывод. Заморозка должна включать резервную копию, список установленных компонентов, инструкцию восстановления и владельца дальнейшей проверки. Это временная базовая линия, а не разрешение никогда не обновляться.

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

Если в лаборатории нет безопасной среды для такой проверки, можно сначала использовать изолированный удалённый Mac с обезличенным набором данных. Описание удалённого доступа VPSNIX поможет оценить этот вариант до изменения общей инфраструктуры. Для долгой тяжёлой пакетной обработки, физического оборудования и закрытых сетей аренда не заменяет собственную лабораторную систему; для краткой приёмки и параллельного теста она часто удобнее покупки отдельного Mac.

SECTION 09 Итог: что сделать на этой неделе

Сначала выгрузите список приложений, плагинов, библиотек, командных инструментов и лицензий. Затем выберите один представительский рабочий процесс для каждой группы и повторите его на изолированном Apple Silicon Mac. До получения доказательств не удаляйте проверенную macOS 27-среду и не объявляйте миграцию успешной только по факту запуска приложения.

Если ваш текущий вариант — единственный старый Mac в лаборатории, он создаёт риск отказа оборудования, не даёт безопасно проводить параллельные эксперименты и заставляет делить одну среду между диссертацией и тестированием. Покупка отдельной машины, напротив, может оказаться нерациональной для короткой проверки, особенно когда нужны лишь обезличенный образец и несколько сеансов приёмки. В такой ситуации аренда удалённого Mac через VPSNIX позволяет сначала проверить миграцию без вмешательства в единственную производственную систему; после сравнения результатов вы решите, нужен ли постоянный Apple Silicon, сохранение macOS 27 или временный двойной контур.

Дополнительно

• Stata 19 на Apple Silicon: руководство для университетов
• FSL 6.0.7–6.0.23 на Mac или Linux: научный выбор платформы
• Установка DeepLabCut 3.0.1 на Mac без CUDA