Как проверить Mac App перед нотариализацией в macOS 27? Чек-лист 2026

В примечаниях к выпуску macOS 27 Apple указывает поддержку только Apple silicon — это ограничение целевой среды, а не подтверждение совместимости или успешной нотариализации приложения (описание macOS 27). Поэтому для прямой доставки Mac App проверяйте именно финальный файл: подпись Developer ID, результат notarytool, обработку билета и запуск приложения. Для Mac App Store действует отдельный путь выпуска. Сначала проведите приёмку на изолированной сборке, затем применяйте проверенную процедуру к релизу.

Материал предназначен независимым разработчикам, напрямую распространяющим Mac App и проверяющим подпись, нотариализацию и комплект поставки.
Он также подойдёт командам, выбирающим между DMG и PKG, и тем, кому нужен постоянный Mac для повторяемой проверки публикации.

Последняя проверка: 6 ноября 2026 года. Факты о процедурах сверены с документацией Apple для нотариализации, распространения и выпуска macOS 27. Перед релизом проверьте актуальные требования по тем же официальным источникам: Apple может обновлять процесс и поддерживаемые среды.

Что именно считается пройденной приёмкой

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

Apple описывает нотариализацию как часть подготовки ПО macOS к распространению вне Mac App Store. В руководстве перечислены, в частности, требования к подписи и Hardened Runtime; конкретный процесс следует сверять с официальным руководством по нотариализации macOS-программ. Это исходные требования платформы. Следующие ниже проверки запуска и сохранения доказательств — проектная приёмка: они помогают сделать выпуск воспроизводимым, но не заменяют требования Apple.

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

Достаточно ли успешного ответа нотариализации, чтобы выпускать приложение? Нет. Он подтверждает результат обработки отправленного объекта, но не заменяет проверку подписанного артефакта, конечного контейнера и запуска в целевой среде. Эти доказательства нужно фиксировать отдельно.

Прямая доставка: Developer ID и приложение

Если приложение загружается с сайта разработчика или распространяется другим способом вне Mac App Store, начните с подписи. Apple относит Developer ID и Hardened Runtime к существенным составляющим процесса прямого распространения; подробности приведены в руководстве Apple о Hardened Runtime и описании служб подписи кода.

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

Для предварительного контроля можно использовать встроенные инструменты macOS. Например, команда ниже проверяет подпись приложения; путь нужно заменить на путь к проверяемому экземпляру:

codesign --verify --deep --strict --verbose=2 "/путь/к/Приложение.app"

Это команда для приёмки, а не рекомендация подписывать приложение с --deep. Для диагностики идентичности подписи отдельно изучите вывод:

codesign -dv --verbose=4 "/путь/к/Приложение.app"

Сохраните полный вывод команды, путь к артефакту и идентификатор сборки. Не записывайте в отчёт только «подпись прошла»: без имени проверенного файла и идентичности этот вывод трудно связать с релизом.

Как понять, что нотариализация завершилась успешно? Свяжите ответ notarytool с конкретной отправкой: сохраните идентификатор отправки, статус и журнал результата. В документации Apple описаны варианты настройки процесса через notarytool и работа с результатами в руководстве по настройке процесса нотариализации. В автоматизации используйте команды, соответствующие выбранному процессу, например ожидание результата при отправке и запрос журнала по идентификатору отправки. Не переносите секреты учётной записи в открытые логи CI.

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

Первый этап: зафиксируйте воспроизводимую сборку

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

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

DMG и PKG: проверяйте не один и тот же объект

DMG и PKG — разные способы доставки, поэтому единая отметка «приложение нотариализовано» не покрывает весь путь установки. У DMG пользователь скачивает и монтирует образ, затем открывает приложение. У PKG пользователь запускает установщик, который размещает приложение в выбранном месте. Состав проверки должен отражать именно эту разницу.

Apple публикует отдельные рекомендации по упаковке Mac-программ для распространения. Используйте их, чтобы сопоставить формат поставки, структуру артефакта и предназначенные для него проверки. Не переносите проверку DMG на PKG механически: у пакета есть собственный этап установки, который нужно проверить, а не выводить из того, что приложение внутри пакета подписано.

Нужно ли заново проверять DMG или PKG после изменения файла? Да, если изменение затрагивает конечный объект или его содержимое. Заменённое приложение внутри DMG, пересобранный образ или заново созданный PKG — новый кандидат на выпуск. Привяжите новый результат notarytool и проверку запуска к обновлённому артефакту; прежняя запись не подтверждает изменённый файл.

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

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

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

Mac App Store: другой путь выпуска

При распространении через Mac App Store не следует копировать процедуру прямой доставки Developer ID как будто это обязательный отдельный этап для того же релизного маршрута. Apple описывает распространение через магазин и прямую доставку как разные варианты; границы этих сценариев изложены в официальном обзоре способов распространения приложений.

Для магазинного выпуска принимайте не произвольный DMG или PKG, а цепочку от архива проекта до отправки и опубликованной сборки. Проверьте, что загружен ожидаемый архив, обработаны замечания в интерфейсе подачи, тестировалась нужная сборка и опубликованный вариант соответствует тому, что команда одобрила. Требования и результат магазинной проверки не следует представлять как тождественные прямой нотариализации: здесь важны правила и статус именно выбранного канала распространения.

Нужно ли приложению из Mac App Store отдельно проходить тот же процесс нотариализации? Для целей этой инструкции — нет: нельзя автоматически применять к магазинной поставке контрольный список прямого распространения и объявлять его обязательным отдельным маршрутом. Ориентируйтесь на актуальную документацию Apple для отправки в магазин и фиксируйте статус релиза в этой цепочке.

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

Как учитывать macOS 27 и выбрать целевую среду

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

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

Можно ли завершить приёмку на удалённом Mac? Да, если среда позволяет выполнить нужные операции и сохранить воспроизводимые доказательства: сведения о системе и инструментах, подпись, отправку через notarytool, журнал результата и запуск конечного файла. Удалённый доступ не меняет требования Apple. Он меняет то, как команда организует доступ к среде, хранит учётные данные и передаёт артефакты.

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

Порядок приёмки: от изолированной сборки до релиза

Сначала выберите маршрут: прямое распространение, DMG, PKG или Mac App Store. Далее последовательно выполните проверки. Каждый шаг должен оставлять свидетельство, по которому другой участник команды сможет восстановить, что именно проверялось.

1. Зафиксируйте целевой канал. Укажите, будет ли приложение отправлено напрямую или через Mac App Store. Для прямой поставки отметьте конечный формат — приложение, DMG либо PKG. Не начинайте с общего статуса «готово к выпуску»: он скрывает различия между маршрутами.

2. Соберите изолированный кандидат. Используйте отдельную сборку, предназначенную для проверки, и присвойте ей однозначный идентификатор. Сохраните параметры сборки, сведения о версии и архитектуре. Не заменяйте файлы внутри кандидата после начала приёмки.

3. Проверьте подпись и требования маршрута. Для прямого распространения сверьте Developer ID, подпись компонентов и Hardened Runtime с рекомендациями Apple. Запишите вывод локальной проверки подписи. Для магазинного пути зафиксируйте соответствие архива и параметров подачи требованиям Apple для магазина.

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

5. Проверьте билет и финальную упаковку. Примените предусмотренную Apple проверку к типу объекта. Если используется DMG, сопоставьте его содержимое с проверенной сборкой. Если используется PKG, проверяйте пакет и последующую установку отдельно. Зафиксируйте имя, путь и контрольную сумму конечного файла, если проект использует контрольные суммы.

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

7. Сверьте комплект перед публикацией. Сопоставьте опубликованный файл с проверенным кандидатом. Проверьте, что журнал, результат запуска и сведения о подписи относятся к одному релизу. Если менялись бинарные файлы, ресурсы, контейнер или путь распространения, вернитесь к соответствующим этапам.

Условия выбора процедуры

• Если приложение доставляется напрямую как отдельный объект, проверьте Developer ID, Hardened Runtime, результат notarytool, билет и запуск этого объекта. Иначе — используйте маршрут, соответствующий фактическому формату доставки, не называя внутреннюю проверку приложения полной приёмкой контейнера.
• Если пользователь скачивает DMG, проверяйте образ и запуск приложения после монтирования. Если используется PKG, замените проверку монтирования установкой пакета и последующей проверкой установленного приложения.
• Если релиз отправляется в Mac App Store, проверяйте магазинную цепочку и опубликованный результат; не добавляйте к ней процедуру прямой доставки только по привычке.
• Если нужен повторяемый тест на macOS 27, подтвердите доступность целевой среды на Apple silicon и отдельно проверьте совместимость проекта. Если нет возможности получить подходящую среду или сохранить доказательства, не объявляйте тест пройденным.
• Если изменился финальный файл после проверки, вернитесь к проверке изменённого объекта. Если файл не менялся и проверка прослеживается до конкретной сборки, можно использовать сохранённые доказательства для этого же кандидата.

Какие записи оставить для команды

Минимальный протокол должен позволять ответить на вопрос: «Какой именно файл проверили и что произошло после этого?» Сохраните сведения о версии и идентификаторе сборки, целевой архитектуре и системе, способе доставки, идентичности подписи, результатах notarytool, проверке билета и запуске. Для DMG добавьте сведения о монтировании и запуске из образа. Для PKG — результат установки и расположение приложения после неё.

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

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

Когда имеет смысл постоянная среда Mac

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

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

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