Декларативные обновления Apple: macOS 27 Golden Gate

По данным Apple, macOS 27.0 beta 4 вышла 20 июля 2026 года, а финальная версия macOS 27 Golden Gate на 9 августа 2026 года ещё не подтверждена. (developer.apple.com)

Симптом: консоль показывает, что старая команда обновления отправлена, но узел с macOS 27.0 не переходит к загрузке или установке.

Самое быстрое решение: не ждать финального релиза. До перехода рабочих узлов на macOS 27 перенесите управление обновлениями на декларативные конфигурации, Apple Software Lookup Service и подписку на отчёты состояния.

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

Эта инструкция предназначена для IT-администраторов, которые всё ещё отправляют обновления macOS через старые MDM-команды, запросы состояния или профили задержки.

Она также нужна платформенным инженерам, отвечающим за удалённые Mac, CI Runner и бессрочно работающие узлы. Отдельный сценарий — смешанный парк macOS 26 и macOS 27, где нельзя одной политикой одновременно управлять старыми и новыми механизмами.

Последнее обновление: 9 августа 2026 года. Данные сверены с текущими материалами Apple для macOS 27 beta, документацией по декларативному управлению обновлениями и описанием Apple Software Lookup Service. Финальная версия macOS 27, её дата выхода, итоговая сборка и список известных проблем пока не подтверждены Apple. (developer.apple.com)

Старый MDM-процесс против декларативной модели

Проблема не в том, что сервер MDM получает успешный HTTP-ответ. Проблема в том, что команда может быть принята серверной инфраструктурой, но больше не приводить устройство к нужному состоянию.

Apple описывает декларативную модель иначе: сервер не пытается каждый раз «запустить» обновление, а объявляет желаемую версию, срок установки и параметры политики. Устройство само проверяет доступный релиз, загружает его, подготавливает установку и сообщает о каждом изменении состояния. (developer.apple.com)

В macOS 27.0 нельзя считать надёжным основанием следующие старые элементы:

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

Apple уже помечает старые ключи задержки обновлений как устаревшие для macOS 26 и более новых систем. Для macOS 27 это особенно важно: оставленный профиль может продолжать существовать в MDM, но его наличие не означает, что он управляет поведением узла. (developer.apple.com)

Почему macOS 27 может не принять старую команду обновления?

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

Для миграции составьте инвентаризацию не только команд, но и всей цепочки:

1. Кто инициирует обновление.
2. Как определяется доступный релиз.
3. Где задаётся задержка.
4. Как выбирается целевая группа устройств.
5. Как фиксируется подготовка к установке.
6. Как проверяется авторизация перезагрузки.
7. Как узел возвращается в рабочий пул.

Если один из этих пунктов по-прежнему зависит от старой команды или старого запроса, процесс нельзя считать готовым к macOS 27.

Что именно заменить, а что оставить

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

Используйте такую карту миграции:

• Команда запуска обновления → декларация SoftwareUpdateEnforcementSpecific.
• Запрос доступной версии → регулярная проверка Apple Software Lookup Service.
• Проверка текущей версии → статус StatusDeviceOperatingSystemVersion.
• Проверка сборки → статус StatusDeviceOperatingSystemBuildVersion.
• Проверка загрузки и подготовки → StatusSoftwareUpdateInstallState.
• Причина запуска → StatusSoftwareUpdateInstallReason.
• Причина сбоя → StatusSoftwareUpdateFailureReason.
• Проверка применённой декларации → статус обработанных деклараций и идентификатор конфигурации.
• Внутреннее согласование релиза → можно сохранить в прежнем виде, если оно не зависит от устаревшего ключа задержки.

Apple указывает, что сервис управления должен подписаться на отчёты о версии ОС, сборке, ожидающей версии, состоянии установки и причине сбоя. Изменения приходят при изменении состояния, а полный отчёт обычно отправляется примерно раз в сутки. Это важное отличие от периодического ручного опроса: ваш сервер должен обрабатывать события и уметь восстанавливать состояние после пропущенного сообщения. (developer.apple.com)

Для проверки доступности конкретного релиза используйте официальный Apple Software Lookup Service. Он возвращает опубликованные обновления и позволяет сопоставить релиз с поддерживаемыми устройствами до создания декларации.

Минимальное доказательство успешной миграции состоит из трёх частей:

• декларация присутствует и активна на нужном устройстве;
• целевая версия и сборка доступны для конкретной модели;
• статус установки продолжает возвращаться после перехода от waiting к downloading, prepared, installing, а затем к новому статусу версии ОС.

Первая проверка: политика задержки без старых ключей

Можно ли в macOS 27 продолжать использовать задержку системного обновления через MDM?

Да, задержку как управленческую задачу сохранять можно, но нельзя строить её на прежней модели конфигурационных профилей. Apple предлагает декларативную конфигурацию SoftwareUpdateSettings, где задержки разделяются на крупное обновление ОС, обычное обновление ОС и системные обновления. Для macOS значения периодов задержки ограничены диапазоном от 1 до 90 дней. (support.apple.com)

Разделите три режима, иначе одна политика будет давать неверный результат:

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

Не смешивайте задержку доступности релиза и дедлайн обязательной установки. Первая определяет, когда обновление появляется в интерфейсе. Вторая задаёт момент, после которого устройство должно перейти к установке. Для принудительного сценария Apple использует TargetOSVersion, необязательный TargetBuildVersion и TargetLocalDateTime. Если версия или сборка ещё не опубликованы, декларация остаётся активной, но устройство не сможет начать обновление. (support.apple.com)

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

Вторая проверка: смешанный парк macOS 26 и macOS 27

Как безопасно обновлять смешанную среду macOS 26 и macOS 27?

Не используйте один предикат «устройство принадлежит группе Mac». Разделите парк минимум по текущей версии ОС, поддерживаемой модели и уровню управления:

• macOS-26-legacy — узлы, которые ещё используют старые процедуры и нуждаются в отдельном плане миграции.
• macOS-26-ddm-ready — узлы, на которых уже проверены декларации, статусы и авторизация.
• macOS-27-pilot — непроизводственные устройства для проверки Golden Gate.
• macOS-27-production — узлы, допущенные к ограниченному выпуску.
• retire-or-replace — устройства, которые не проходят требования для удалённого обновления.

Для каждого узла проверяйте четыре значения:

1. Фактическую версию macOS.
2. Фактическую сборку.
3. Поддерживаемость аппаратной модели для выбранного релиза.
4. Идентификатор и область действия декларации.

Сервис управления должен сопоставлять доступный релиз со списком поддерживаемых устройств. Нельзя считать, что наличие macOS 27 в каталоге автоматически означает применимость к каждому Mac в группе.

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

Выход из двойного режима наступает после двух событий:

• узлы macOS 27 стабильно подтверждают декларацию, целевую сборку, установку и возврат статуса;
• для оставшихся узлов macOS 26 есть дата обновления, замены или вывода из эксплуатации.

Третья проверка: Apple silicon без оператора

На бессрочно работающем Apple silicon Mac успехом нельзя считать только появление новой версии в отчёте. Сначала проверьте, сможет ли устройство авторизовать обновление без присутствия пользователя.

Apple описывает следующие условия для бесшовного принудительного обновления:

• устройство находится под надлежащим управлением;
• сервер запрашивает и сохраняет Bootstrap Token;
• MDM-профиль объявляет способность сервера работать с com.apple.mdm.bootstraptoken;
• токен создан после входа пользователя с Secure Token;
• токен передан и сохранён на стороне сервиса;
• локальный пользователь или процесс не блокирует перезапуск;
• для Apple silicon выполнены требования владельца тома. (developer.apple.com)

Проверяйте не только наличие токена в базе. Запросите у устройства подтверждение, что Bootstrap Token требуется для обновления, затем сопоставьте это с фактом escrow. Если авторизация не подтверждена, производственный узел не должен попадать в волну принудительной установки.

После активации декларации ожидайте последовательность:

• waiting — устройство приняло процесс и ожидает начала;
• downloading — загрузка началась;
• prepared — пакет подготовлен;
• installing — установка выполняется;
• failed — произошла ошибка.

После перезагрузки должны появиться новая версия ОС, новая сборка и причина запуска, где для декларативного процесса указывается declaration. Именно этот набор подтверждает, что обновление было выполнено нужным механизмом, а не случайно запущено пользователем или командной строкой.

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

Четвёртая проверка: CI Runner до и после перезагрузки

Для CI Runner проверка версии ОС занимает последнее место. Сначала проверяйте рабочий цикл задания.

Порядок испытания:

1. Выведите тестовый Runner из пула или поставьте его в режим drain.
2. Дождитесь завершения текущих заданий.
3. Сохраните идентификатор узла, состояние агента и привязанные метки.
4. Назначьте декларацию только тестовой группе.
5. Убедитесь, что декларация активирована.
6. Проверьте переход статусов загрузки и подготовки.
7. Проверьте принудительную установку и авторизацию перезапуска.
8. После загрузки дождитесь нового отчёта версии и сборки.
9. Проверьте удалённое подключение.
10. Убедитесь, что CI Agent снова принимает тестовое задание.
11. Выполните сборку, использующую те же инструменты и сертификаты, что и рабочий поток.
12. Верните узел в общий пул только после успешного завершения задания.

Здесь важны четыре независимых результата:

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

Если изменился только номер версии, но агент не принимает задания, узел не прошёл приёмку. Такой результат нельзя компенсировать большим количеством устройств в следующей волне.

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

Декларация macOS 27: какие поля проверить

Как указать версию macOS 27 и время принудительной установки?

В декларации целевого обновления проверьте как минимум:

• TargetOSVersion — целевая версия macOS;
• TargetBuildVersion — конкретная сборка, если она нужна для тестовой или фиксированной волны;
• TargetLocalDateTime — локальное время обязательной установки;
• DetailsURL — необязательная страница с внутренним описанием окна и рисков.

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

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "macos-27-pilot",
  "ServerToken": "уникальный-токен",
  "Payload": {
    "TargetOSVersion": "27.0",
    "TargetBuildVersion": "проверенная-сборка",
    "TargetLocalDateTime": "2026-09-21T01:00:00",
    "DetailsURL": "внутренняя-страница-релиза"
  }
}

Не подставляйте в производственную декларацию сборку из медиа-статьи или старого beta-канала. Если сочетание версии и сборки не совпадает с доступным релизом, устройство сохраняет конфигурацию активной, но обновиться не может. Перед выпуском проверяйте каталог и повторяйте проверку после публикации нового beta, RC или финального релиза. (developer.apple.com)

Приёмочная матрица перед расширением волны

Используйте эту матрицу как единственный выпускной инструмент, а не как справочную заметку.

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

Когда старую схему можно окончательно убрать

Удаляйте старые команды и профили не в момент первой успешной установки, а после завершения переходного периода. До этого сохраните аудит:

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

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

Текущая схема против параллельного Mac

Старая схема на командах выглядит дешевле, пока парк небольшой. Но для удалённых Mac и CI Runner у неё есть реальные недостатки: команда не равна достигнутому состоянию, старые задержки могут быть проигнорированы, а после перезагрузки часто проверяется только версия ОС без проверки CI-агента и удалённого доступа.

Параллельный Mac нужен не каждому узлу. Он оправдан, если производственный Runner нельзя надолго выводить из пула, если нет подтверждённого Bootstrap Token или если после обновления требуется ручная проверка лицензий, сертификатов и сборочных инструментов. В таких случаях временная аренда MacHTML позволяет провести пробный выпуск отдельно от критичного узла, не превращая обновление в остановку всей очереди. Доступные варианты управления и текущие условия можно проверить в справочном разделе MacHTML.

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