Xcode собрал приложение, но стадия нотариального заверения привязывает выпуск к Mac, которого нет в текущем конвейере.
Короткий ответ: для подачи на заверение и проверки статуса Notary API позволяет не зависеть от macOS; для сборки, подписи, прикрепления квитанции и полной приёмки выпуска такая замена Mac не гарантирует. Если ваш выпуск уже проходит через Xcode и macOS, начните с notarytool; переходите к Notary API только тогда, когда вам действительно нужно выполнять взаимодействие с сервисом из Windows или Linux.
Эта статья для вас, если вы выпускаете macOS-приложение вне магазина приложений и отвечаете за его заверение.
Она также пригодится, если вы проверяете, какие части конвейера могут выполняться в Windows или Linux.
Отдельный раздел поможет небольшой команде разделить ответственность за ключи, сборку и финальную приёмку.
SECTION 01 Сначала разделите выпуск на независимые этапы
Слово «заверение» часто используют для всей подготовки приложения к передаче пользователю. Для выбора среды это слишком широкое определение: сервис нотариального заверения принимает подготовленное программное обеспечение и возвращает результат проверки, но это не делает его системой сборки и не превращает публикацию в одну операцию.
Разложите выпуск на отдельные контрольные точки:
- Сборка. Xcode или другая система создаёт приложение и формирует выпускной артефакт. Возможность отправить этот артефакт через API сама по себе не означает, что его можно было собрать в той же среде.
- Подпись. До отправки приложение должно быть подготовлено к распространению и подписано подходящим способом. Apple описывает требования к выпускной подготовке отдельно от взаимодействия с сервисом заверения в документации по подготовке приложения к распространению.
- Подача на заверение. Вы передаёте подготовленный артефакт в сервис через
notarytoolлибо Notary API. - Проверка результата. Отправка запроса — ещё не подтверждение успешного завершения проверки. Нужно получить состояние и при необходимости изучить журнал.
- Прикрепление квитанции и приёмка. После успешного заверения проверьте, требуется ли вашему выпуску прикрепить квитанцию, и испытайте именно тот файл, который будет доставлен пользователям.
В обзоре Notary API Apple описывает взаимодействие с сервисом через API; в описании подачи программного обеспечения через веб-интерфейс API видны отдельные действия для создания подачи, загрузки и проверки её результата. Это не описание универсального API сборки или подписи.
| Контрольная точка | Что решает notarytool |
Что решает Notary API | Что нельзя считать решённым автоматически |
|---|---|---|---|
| Сборка | Команда может быть частью существующего конвейера, но не заменяет проект и настройки сборки | Не предоставляет Xcode и не собирает приложение | Получение готового выпуска из исходного кода |
| Подпись | Работает в процессе, где выпуск уже подготовлен | Не подменяет инструмент подписи | Выбор идентификатора, сертификата и параметров подписи |
| Подача | Командный интерфейс взаимодействует с сервисом заверения | Запросы к сервису можно встроить в собственный конвейер | Подготовка корректного артефакта до отправки |
| Состояние и журнал | Позволяет проверять результат и получать сведения о подаче | Предусматривает отдельное получение состояния и журнала | Разбор причины отказа и исправление самого приложения |
| Квитанция и приёмка | Не следует считать успешную подачу финальной доставкой | Сам API не означает, что квитанция уже прикреплена к файлу | Проверка передаваемого пользователю артефакта |
Удобная граница для архитектурного решения проста: если вы хотите заменить только интерфейс подачи и чтения результата, сравнивайте два способа взаимодействия с сервисом. Если вы хотите перенести весь выпуск с Mac, отдельно докажите, что новая среда покрывает каждую из перечисленных контрольных точек.
SECTION 02
Для кого notarytool останется разумным выбором
Если Xcode уже собирает приложение на Mac, а там же выполняются подпись и подготовка к распространению, notarytool обычно лучше вписывается в уже работающий процесс. Команда может вызывать инструмент из скрипта выпуска, сохранять результат проверки и передавать его дальше по вашему конвейеру. В этом случае отдельная интеграция с REST API может добавить поддержку и хранение секретов, но не убрать основную причину, по которой вам нужен Mac.
Apple документирует установку инструментов командной строки Xcode отдельно; проверьте требования к установке этих инструментов, прежде чем считать, что конкретный исполнитель сборки уже способен запускать нужные команды. Важна не только доступность Xcode как приложения: учтите, где установлены инструменты, под какой учётной записью запускается процесс и откуда скрипт получает полномочия.
Для уже существующего Mac-конвейера решение часто определяется не модой на API, а операционной стоимостью. notarytool означает меньше собственного кода для сетевого взаимодействия и меньше мест, в которых команда должна сопоставлять ответы API со своими внутренними статусами. Собственная интеграция, напротив, может быть оправдана, если у вас уже есть общий исполнитель для разных операционных систем и единый механизм аудита запросов.
Когда имеющийся Xcode-конвейер действительно выиграет от перехода на Notary API? Когда причина конкретна: подачу должны выполнять общие Windows- или Linux-исполнители, команда унифицирует запросы к сервисам, а создание и поддержка интеграции окупаются. Если единственная цель — убрать из Mac-конвейера одну команду notarytool, сначала сравните стоимость поддержки собственного клиента с пользой от такого изменения.
| Профиль выпуска | Предпочтительный первый вариант | Причина выбора | Что проверить до решения |
|---|---|---|---|
| Xcode, подпись и выпуск уже работают на Mac | notarytool |
Сервисная операция остаётся рядом с остальными macOS-этапами | Установлены ли командные инструменты и сохраняются ли журналы |
| Сборка проходит отдельно, подача должна идти из Windows или Linux | Notary API для подачи и проверки | API позволяет отделить взаимодействие с сервисом от Mac-инструментов | Кто готовит и подписывает артефакт, где хранится ключ, кто читает отказ |
| Внешняя система уже выдаёт готовый подписанный артефакт | Сравнить оба подхода на тестовом выпуске | Выбор зависит от среды исполнительного процесса и требований к аудиту | Можно ли выполнить следующие шаги и проверить конечный файл |
| Команда хочет избавиться от Mac на всех этапах | Не считать API достаточным основанием | API снимает зависимость только с взаимодействия с сервисом заверения | Отдельно подтвердить сборку, подпись, прикрепление квитанции и приёмку |
Это не рейтинг инструментов по скорости или «современности». Таблица отделяет потребность вынести API-вызовы из macOS от гораздо более крупной задачи — переноса всего цикла подготовки приложения.
SECTION 03 Для Windows и Linux: переносится подача, а не весь выпуск
Можно ли запускать notarytool в Windows или Linux? Не стройте план выпуска на предположении, что инструмент командной строки Apple доступен там так же, как на Mac. Документация связывает эти инструменты с установкой средств командной строки Xcode; если вашим исполнителям Windows или Linux нужно обращаться к сервису напрямую, рассматривайте Notary API, а возможность выполнять остальные задачи проверяйте отдельно.
Именно здесь Notary API полезен: в официальном описании Apple взаимодействие с сервисом не требует macOS. Это позволяет выделить подачу, проверку состояния и чтение журнала в отдельную часть конвейера, не превращая API в замену Xcode. Потребность в Mac может сохраниться на предыдущем этапе — при создании или подписании приложения — и на последующем — при подготовке файла к доставке.
Для команды, которая выпускает приложение из внешней системы сборки, сначала зафиксируйте входные и выходные данные каждого этапа. Например, назначьте конкретный процесс, который отвечает за готовый выпускной файл; определите, где выполняется его подпись; затем решите, кто создаёт подачу и кто проверяет результат. Такой контракт между этапами важнее выбора между командой и REST-запросом: без него успешный ответ API может быть принят за завершённый релиз, хотя артефакт ещё не прошёл проверку перед распространением.
Может ли Notary API полностью заменить notarytool для нотариального заверения приложения? Он может заменить этот инструмент как способ взаимодействия с сервисом, если ваша интеграция реализует требуемые операции. Но это не замена Xcode, подписи или средств macOS, необходимых вашей конкретной процедуре выпуска. Сверяйте не названия инструментов, а перечень действий: отправка, ожидание результата, чтение журнала и дальнейшая обработка файла.
Отдельный риск — разрыв между тем, кто получил ответ сервиса, и тем, кто отвечает за релиз. Если API-клиент сообщает об успешном состоянии, а другой процесс должен прикрепить квитанцию, у вас должны быть явный владелец этого этапа и проверка полученного файла. Иначе автоматизация будет успешно завершать технический запрос, но не обязательно выпуск, который вы готовы отдать пользователю.
SECTION 04 Владельцам артефакта: журнал, квитанция и приёмка
Успешный ответ о завершении заверения — контрольная точка, а не сокращённое название всего выпуска. Сохраните связь между отправленным артефактом, идентификатором подачи, полученным результатом и файлом, который проходит финальную проверку. Если сервис сообщает о проблемах, журнал нужен не для формального отчёта, а чтобы команда могла найти конкретную причину и исправить выпуск.
Apple отдельно описывает настройку собственного рабочего процесса заверения. Используйте эту документацию, чтобы определить, какие действия входят именно в ваш сценарий. Не предполагайте, что API-запрос прикрепит квитанцию автоматически: отправка, обработка ответа и операция с локальным файлом — разные обязанности, даже если их вызывает один сценарий выпуска.
Нужно ли запускать stapler, если подача выполнена не на Mac? Не выводите необходимость этой операции только из того, что подача прошла через API. Проверьте требования вашего способа доставки и используйте предназначенные для него средства прикрепления квитанции; затем проверьте конечный артефакт. Документация Apple по рабочему процессу и разбору распространённых проблем с заверением полезны для проверки результата и диагностики. Если этап прикрепления требует средства macOS в вашем сценарии, выделите для него Mac, даже когда подачу выполнял Linux-процесс.
Чтобы выпустить приложение, не ограничивайтесь проверкой ответа API. Пройдите контрольные действия в том порядке, который соответствует вашей архитектуре:
- Зафиксируйте, какой именно файл является входом для подачи, и свяжите его с конкретной сборкой и подписью.
- Убедитесь, что процесс подачи получает этот файл и использует подходящий способ аутентификации.
- Сохраните идентификатор подачи и результат, чтобы следующий этап мог запросить состояние, а не полагался на неподтверждённое сообщение в консоли.
- Если заверение завершилось ошибкой, сохраните журнал и разберите его до повторной отправки; рекомендации Apple по устранению типичных проблем помогают отличить проблемы процесса от проблем самого выпуска.
- Определите, где и кем выполняется прикрепление квитанции, если оно нужно вашему сценарию. Не считайте его выполненным только потому, что подача принята или завершилась успешно.
- Проверьте конечный файл после заверения и обработки. Тестируйте тот артефакт, который попадёт к пользователю, а не только первоначальную сборку.
- Перед публикацией убедитесь, что в логи не попали содержимое закрытого ключа, токен или другие повторно используемые данные доступа.
Не смешивайте «запрос принят», «проверка завершена успешно» и «готовый файл прошёл приёмку». Это разные состояния конвейера, и для каждого нужен отдельный наблюдаемый результат.
SECTION 05 Для ответственного за ключи: не переносите секреты вместе с логами
У Notary API своя зона ответственности за доступ. В описании Apple для работы с API указана аутентификация с помощью JWT; при проектировании клиента нужно учитывать, где находится ключ, кто может сформировать запрос и какие полномочия вы выдаёте этому процессу. Это отдельное решение от выбора операционной системы для исполнителя: доступность API из Windows или Linux не делает безопасным хранение ключа в открытом виде в переменных скрипта или в журнале сборки.
У notarytool и собственного API-клиента различается объём кода, который вам предстоит поддерживать. Командный инструмент позволяет строить выпуск вокруг уже подготовленной команды, тогда как собственная интеграция требует корректно реализовать запросы, обработку ответа и диагностику ошибок. В любом варианте ограничьте круг процессов, которым доступен секрет, и не выводите его значения в диагностический вывод. Если команда использует временные данные для загрузки, обращайтесь с ними как с секретами, пока не проверите их назначение и срок действия по официальным материалам; не превращайте такие параметры в постоянные настройки и не копируйте их в примеры.
Перед внедрением проведите небольшую проверку управления доступом:
- выделите отдельное место хранения для ключа, а не добавляйте его в репозиторий или файл конфигурации проекта;
- ограничьте круг исполнителей, которым разрешено запускать подачу;
- проверьте, что журналы, артефакты диагностики и сообщения об ошибках не раскрывают повторно используемые данные;
- назначьте владельца, который может отозвать доступ и обновить конфигурацию при изменении состава команды;
- проверьте путь от ответа API до выпускаемого файла: секрет для подачи не должен быть нужен пользователю приложения.
Эти меры не делают один инструмент автоматически безопаснее другого. Сравнивайте полный путь секрета: получение, хранение, использование исполнителем, запись в журнал и отзыв. В собственной интеграции добавляется ещё один участок кода, который нужно проверить; в командном сценарии всё равно остаётся ответственность за безопасную передачу параметров процессу.
SECTION 06 Как выбрать маршрут по условиям вашего выпуска
Используйте условия как решение о распределении этапов, а не как рекомендацию отказаться от конкретной платформы:
- Если Xcode собирает и подписывает приложение на Mac, а команда уже поддерживает этот выпуск, выбирайте сначала
notarytool. Не создавайте API-клиент без конкретной потребности, которую он решает. - Если готовый артефакт передаётся в общий конвейер, работающий на Windows или Linux, и подавать его нужно именно из этой среды, оцените Notary API для подачи, запроса состояния и чтения журнала.
- Если задача звучит как «полностью выпускать macOS-приложение без Mac», не принимайте Notary API за достаточное решение. Сначала отдельно подтвердите возможность сборки, подписи, прикрепления квитанции и проверки конечного файла.
- Если у команды нет владельца ключа, обработки ошибок или приёмки артефакта, не переводите выпуск в автоматический режим. Сначала назначьте ответственных и добавьте проверяемые результаты для каждого этапа.
- Если новая интеграция нужна только для одного запроса из уже работающего Mac-конвейера, сравните расходы на поддержку собственного клиента с сохранением
notarytool. При отсутствии явной операционной выгоды оставьте существующий инструмент.
Перед изменением рабочего процесса проверьте его на собственном проекте: соберите обычный выпуск, запустите подачу выбранным способом, сохраните журнал и проследите, какой инструмент выполняет все действия после ответа сервиса. В конце сопоставьте контрольную сумму или иной принятый в вашей команде идентификатор артефакта до и после обработки, чтобы подтвердить, что на тестирование и доставку пошёл именно ожидаемый файл.
Если для этой проверки нужен отдельный доступ к macOS, сначала выясните, какие способы подключения и работы описаны в справочном центре VPSNIX. Затем оцените варианты по условиям вашей команды, а не по обещанию заменить одной системой всю инфраструктуру выпуска.
Для текущего варианта на Windows или Linux есть практические минусы: подача через API не создаёт недостающий Xcode, вам придётся самостоятельно поддерживать клиент и безопасно хранить ключ, а выполнение операций с квитанцией и приёмка всё ещё могут требовать отдельного macOS-этапа. Если вам нужен временный Mac для проверки сборки, подписи или обработки готового выпуска, аренда Mac у VPSNIX может дать доступ к macOS-инструментам без покупки отдельного компьютера. Сверьте условия на странице тарифов VPSNIX и используйте Mac только для тех частей процесса, которым он действительно нужен: Notary API остаётся вариантом для подачи и проверки, а не обязательной заменой всего конвейера.