Как нотариально заверить приложение macOS? Чек-лист публикации с удалённого Mac на 2026 год

Канал распространения и граница проверки

Нотариальная проверка Apple и рассмотрение приложения для App Store — разные процессы. Если приложение предназначено для прямой загрузки с сайта или передачи клиенту, ориентируйтесь на распространение вне App Store: подпишите его подходящим сертификатом Developer ID, отправьте артефакт на проверку, обработайте результат и проверьте поставляемую копию. Документация Apple отдельно описывает распространение приложений разными способами и нотариальную проверку macOS-программ перед распространением.

Таблица помогает выбрать маршрут, но не обещает положительный результат проверки: Apple рассматривает конкретный подписанный артефакт, а ошибки сборки, подписи или настроек могут потребовать исправления. Для нотариального процесса сертификат Developer ID Application используется для подписи приложения, а Developer ID Installer предназначен для подписания установочного пакета. Это два разных типа сертификатов, и выбор зависит от того, что именно передаётся пользователю. Типы и назначение сертификатов приведены в документации Apple по созданию сертификатов Developer ID.

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

Подготовка перед поездкой: учётная запись и доступы

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

До отъезда проверьте:

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

security find-identity -v -p codesigning

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

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

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

Может ли удалённый Mac пройти нотариальную проверку приложения macOS

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

Перед рабочим выпуском выполните пробный проход на тестовой сборке. Проверьте, что:

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

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

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

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

На этапе сборки проверьте настройки подписи в Xcode, соответствие команды и идентификатора приложения, а также включение Hardened Runtime там, где оно требуется для выбранного процесса распространения. Apple отдельно описывает настройку Hardened Runtime для Xcode. Не переносите параметры от другого проекта автоматически: entitlements должны соответствовать функциям конкретного приложения.

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

codesign --verify --deep --strict --verbose=2 "/путь/к/MyApp.app"

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

Чтобы посмотреть сведения о подписи приложения, выполните:

codesign -dv --verbose=4 "/путь/к/MyApp.app"

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

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

Отправка и отслеживание запроса

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

xcrun notarytool submit "/путь/к/MyApp.zip" \
  --keychain-profile "профиль-команды" \
  --wait

Если команда завершилась до получения итогового результата, сохраните идентификатор отправки и запросите состояние отдельно:

xcrun notarytool info "<идентификатор-запроса>" \
  --keychain-profile "профиль-команды"

При отказе или необходимости разобраться в предупреждениях запросите журнал:

xcrun notarytool log "<идентификатор-запроса>" \
  --keychain-profile "профиль-команды"

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

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

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

Обработка результата: билет и конечный файл

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

xcrun stapler staple "/путь/к/MyApp.app"
xcrun stapler validate "/путь/к/MyApp.app"

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

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

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

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

Итоговый выбор удалённой среды

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

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

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

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

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