Electron 44: нужен ли Mac для сборки macOS? CI-схема 2026

Материал предназначен для разработчиков, которые ведут Electron-проект в Windows или Linux и впервые готовят выпуск под macOS. Здесь также найдут схему DevOps-специалисты, подключающие Electron Forge, подпись и notarization к автоматической сборке.

Техническим руководителям статья поможет сравнить краткосрочную аренду Mac, покупку отдельного компьютера и постоянно работающий выпускной узел. Мы обсуждаем не демонстрационный .app, а установщик, который можно передать пользователю и поддерживать обновлениями.

Состояние документации и выводы по инструментам проверены 11 сентября 2026 года. Фактические сведения сверены с документацией Electron, Electron Forge и Apple.

У Electron есть несколько разных операций, которые часто называют одним словом «сборка». Для принятия решения их нужно разделить:

• упаковка — формирование приложения и установщика;
• сборка нативных зависимостей — подготовка модулей под darwin-arm64, darwin-x64 или универсальный вариант;
• кодовая подпись — проверка происхождения приложения и его компонентов;
• notarization — отправка подписанного продукта на автоматическую проверку Apple;
• stapling — присоединение подтверждения к локальному артефакту;
• установка и запуск — контроль поведения в чистой среде;
• автообновление — проверка, что следующая версия также принимается системой.

Обзор распространения Electron прямо разделяет эти стадии. Поэтому зелёный job на Windows ещё не доказывает, что пользователь получит устанавливаемое приложение. Неподписанный пакет может быть достаточен для внутреннего теста, но не для стабильной публичной поставки.

Важно. Нельзя считать успешную упаковку доказательством совместимости. В выпускном отчёте отдельно фиксируйте путь к артефакту, результат подписи, статус notarization, stapler-проверку и запуск в чистой учётной записи.

Что можно оставить на Windows или Linux

На универсальном узле обычно выполняются:

• форматирование, lint и статический анализ;
• модульные и интеграционные тесты, не требующие macOS;
• проверка бизнес-логики Electron main process и renderer;
• подготовка changelog и метаданных релиза;
• сборка исходного архива;
• проверка хэшей и публикация промежуточного артефакта.

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

Что должно перейти на Mac

На Mac-узле выполняются операции, для которых важна сама macOS:

• окончательная сборка приложения под целевую архитектуру;
• загрузка и проверка нативных модулей;
• подписание приложения и вложенных компонентов;
• notarization через notarytool или Notary API;
• stapling и проверка билета;
• запуск установщика в чистой учётной записи;
• проверка разрешений, Keychain-интеграции, login items и автообновления.

Именно здесь Electron 44 macOS сборка превращается из файла на диске в проверяемый продукт.

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

Последняя схема даёт лучший баланс. Mac не простаивает на lint и универсальных тестах, а Linux или Windows не пытаются заменить macOS там, где это уже невозможно.

Чистый JavaScript-проект может собраться на одной системе и выглядеть переносимым. Ситуация меняется, если в package.json есть Node-модули с бинарными компонентами, вспомогательные executable-файлы, системные расширения или платформенные ресурсы.

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

• darwin-arm64;
• darwin-x64;
• universal binary, если его действительно поддерживает конкретная зависимость.

Инструкция Electron по платформам и архитектурам объясняет, что установка и использование Electron зависят от целевой платформы. Это не означает, что любой npm-пакет автоматически готов к обеим архитектурам.

Проверка без догадок

На Mac создайте чистую рабочую директорию и повторите установку зависимостей. Не переносите готовый node_modules с Windows или Linux. Затем:

1. зафиксируйте версию Node.js, пакетного менеджера и Electron;
2. удалите предыдущие зависимости и lock-файлы только по утверждённой процедуре;
3. выполните чистую установку из commit ID релиза;
4. пересоберите нативные модули для выбранной архитектуры;
5. запустите приложение до подписи;
6. проверьте загрузку каждого критичного native module;
7. сохраните список бинарных файлов и их архитектуры;
8. повторите проверку на целевой машине пользователя или в чистой учётной записи.

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

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

Для распространения Electron-приложения под macOS кодовая подпись — отдельный обязательный этап, а не флаг упаковщика. В документации Electron по code signing описана роль сертификатов и подписи компонентов приложения.

В выпускной задаче участвуют:

• сертификат Developer ID;
• приватный ключ в Keychain;
• entitlements;
• Hardened Runtime;
• Bundle ID;
• учётная запись, от имени которой запускается runner;
• настройки доступа к ключевой цепочке.

Руководство Electron Forge для подписи macOS и типовые параметры @electron/osx-sign полезны именно как рабочая спецификация конфигурации. Параметры вроде identity, optionsForFile и entitlements должны быть привязаны к конкретному проекту, а не скопированы без проверки.

В примерах используйте только заполнители:

• TEAM_ID_PLACEHOLDER;
• BUNDLE_ID_PLACEHOLDER;
• CERTIFICATE_NAME_PLACEHOLDER;
• KEYCHAIN_PATH_PLACEHOLDER;
• REPOSITORY_PLACEHOLDER;
• COMMIT_SHA_PLACEHOLDER.

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

Контрольный список подписи

• [ ] Сертификат доступен только выпускному пользователю.
• [ ] Keychain разблокируется в контролируемом CI-шаге.
• [ ] Entitlements хранятся рядом с версионируемой конфигурацией.
• [ ] Bundle ID совпадает с настройками проекта.
• [ ] Подписаны приложение и вложенные бинарные компоненты.
• [ ] После подписи проверяется не только наличие сертификата, но и запуск.
• [ ] В логах нет приватных ключей, паролей и секретных токенов.
• [ ] Сбой подписи останавливает pipeline до notarization.

После перезапуска Mac отдельно проверьте, доступен ли Keychain. Автоматизация, которая работает только до первой перезагрузки, не является восстановленной CI-системой.

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

Типовая последовательность выглядит так:

1. получить подписанный архив или установщик;
2. отправить его через notarytool либо Notary API;
3. сохранить идентификатор отправки;
4. дождаться финального статуса;
5. при отказе забрать исходный лог;
6. после успешной проверки выполнить stapling;
7. проверить наличие билета локально;
8. проверить установку в чистой учётной записи;
9. сохранить все результаты вместе с commit ID.

Notary API Apple полезен для команд, которым требуется управлять отправками программно. Независимо от выбранного интерфейса, статус «upload завершён» означает только принятие файла сервисом. Он не равен одобрению.

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

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

Electron Forge разделяет этапы жизненного цикла сборки. Описание build lifecycle помогает определить, где заканчивается общий pipeline и начинается выпускной Mac-job.

Пример разбиения:

Узел Windows или Linux

1. Проверить commit и lock-файл.
2. Выполнить lint и тесты.
3. Собрать универсальный промежуточный артефакт.
4. Проверить метаданные версии.
5. Посчитать хэш архива.
6. Передать COMMIT_SHA_PLACEHOLDER и хэш в выпускной job.
7. Запретить этому узлу доступ к сертификатам.

Узел Mac

1. Получить именно зафиксированный commit или подписанный промежуточный артефакт.
2. Сверить хэш до распаковки.
3. Выполнить чистую установку зависимостей.
4. Собрать macOS-артефакт через настроенный Forge pipeline.
5. Проверить нативные модули.
6. Подписать приложение.
7. Отправить его на notarization.
8. Дождаться результата.
9. Выполнить stapling.
10. Запустить установщик в чистой учётной записи.
11. Проверить автообновление и сохранить логи.

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

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

Краткосрочный удалённый Mac

Подходит, если:

• релизы выходят редко;
• команда впервые строит macOS-пайплайн;
• нужно проверить Electron Forge и native modules;
• Mac требуется только на время миграции;
• покупка оборудования пока не оправдана.

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

Долгосрочный выделенный узел

Оправдан, если:

• релизы идут регулярно;
• есть ночные сборки;
• автообновление нужно проверять на каждом выпуске;
• команда может обслуживать macOS и Keychain;
• простой выпускного конвейера дороже постоянного узла.

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

Общий Mac Runner

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

Зелёный CI-job — только сигнал для перехода к приёмке. Перед передачей установщика команде или пользователям пройдите весь список:

• [ ] Выпуск начат из чистой рабочей директории.
• [ ] Зафиксированы commit ID и хэш исходного артефакта.
• [ ] Зависимости установлены заново на Mac.
• [ ] Нативные модули загружаются на целевой архитектуре.
• [ ] Приложение собрано без неподписанных вложенных бинарных файлов.
• [ ] Сертификат и entitlements соответствуют проекту.
• [ ] Notarization завершена положительным статусом.
• [ ] Сохранен исходный лог нотариальной проверки.
• [ ] Stapling выполнен для конечного файла.
• [ ] Билет проверен локально.
• [ ] Установщик запущен в чистой учётной записи.
• [ ] Первый запуск проверен после отключения сети.
• [ ] Автоматическое обновление протестировано с предыдущей версии.
• [ ] После перезапуска Mac runner снова выполняет выпускной job.
• [ ] Предыдущий работоспособный установщик сохранён для отката.

Отдельно проверьте, что после перезапуска восстанавливаются не только runner и рабочая директория, но и ожидаемое состояние Keychain. Если восстановление требует ручного входа администратора, это нужно явно указать в runbook.

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

Можно ли выпустить macOS-версию без Mac?

Можно создать неподписанный пакет и выполнить часть упаковки на Windows или Linux. Для публичного выпуска этого недостаточно: нужно проверить macOS-архитектуру, подпись, notarization, stapling и установку. Поэтому вопрос следует формулировать не как «создаётся ли файл», а как «можно ли получить проверенный production-артефакт».

Почему Apple-кодовая подпись возвращает CI к macOS?

Подпись связана с Keychain, приватным ключом, entitlements и инструментами macOS. Даже если часть команд можно вызвать из общего скрипта, ключ должен использоваться в контролируемой среде. Кроме того, результат нужно проверить запуском приложения и поведением системы безопасности. Отдельный Mac ограничивает область доступа и делает выпуск воспроизводимее.

Как Electron Forge подключается к notarization?

Forge отвечает за этапы сборки и подписи в соответствии с конфигурацией проекта. Notarization следует после получения подписанного артефакта. CI передаёт его на Mac, отправляет через notarytool или Notary API, ждёт финальный статус, сохраняет лог и выполняет stapling. Секреты и параметры проекта должны приходить только в выпускной job.

Как Windows-команде публиковать Electron-приложение для Mac?

Разделите pipeline. На Windows выполняйте общие тесты и подготовку исходников. На Mac повторите установку зависимостей для целевой архитектуры, соберите приложение, подпишите его, пройдите notarization, проверьте билет и установку. Между узлами передавайте commit ID и хэш, иначе Mac может собрать код, который не проходил предыдущую проверку.

Нужен ли постоянно работающий Mac для Electron CI?

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

Если сейчас в команде есть только Windows или Linux, не пытайтесь закрыть весь macOS-релиз виртуальным обходом. Такой подход часто оставляет неподписанные вложенные бинарные файлы, не показывает реальное поведение Keychain и переносит ошибку на этап Gatekeeper. Локальный Mac разработчика решает техническую задачу, но создаёт зависимость от одного рабочего места и ручных действий.

Оптимальная первая проверка — короткий выпускной цикл на реальном удалённом Mac: чистый клон, Electron Forge, нативные модули, подпись, notarization, stapling, установка и обновление. В MESHLAUNCH можно выбрать удалённый Mac для тестового CI-цикла, а затем решить, нужен ли постоянный узел. Если релизы редкие, аренда сохраняет гибкость; если сборки идут постоянно и требуют физического доступа, следует оценить собственную машину и резервный выпускной путь.