Упаковка и распространение Electron-приложений

Доставка Electron-приложения реальным пользователям — это четырёхэтапный конвейер: упаковка приложения в нативный установщик для целевой платформы, подпись и нотаризация, чтобы операционные системы доверяли ему, распространение через доступный пользователям канал и настройка автообновления, чтобы они всегда работали с актуальной версией. Первое решение, которое нужно принять, — выбор инструмента для этого конвейера, и в 2026 году выбор сводится к двум вариантам: Electron Forge или electron-builder. В этом руководстве описан полный путь с готовыми к копированию конфигурациями, правилами подписи кода, изменившимися в 2023 и 2024 годах, и рабочей матрицей GitHub Actions, которая собирает сборки для всех трёх платформ параллельно, — потому что кросс-сборку всего из одной машины выполнить невозможно.

Electron Forge против electron-builder в 2026 году

Выбирайте Electron Forge, если вам нужен официально поддерживаемый универсальный конвейер; выбирайте electron-builder, если важны наиболее зрелый встроенный механизм автообновления и широкое присутствие в сообществе. Оба инструмента создают подписанные, поддерживающие обновления установщики для macOS, Windows и Linux. Разница — в модели поддержки и философии, а не в возможностях.

Electron Forge — это официально рекомендованный инструмент проекта. Это универсальное решение для упаковки и распространения Electron-приложений, объединяющее множество узкоспециализированных пакетов в полноценный конвейер сборки, работающий из коробки: с подписью кода, установщиками и публикацией артефактов. Forge поглотил более старые утилиты @electron/packager и @electron/osx-sign, интегрировав их в систему Makers и Publishers. Принципиально важно: если вы не хотите использовать Electron Forge, другие сторонние инструменты поддерживаются членами сообщества Electron и не имеют официальной поддержки от проекта Electron.

electron-builder — это та самая альтернатива от сообщества, причём более загружаемая: порядка 2–3 миллионов установок в неделю в зависимости от источника статистики. По состоянию на июнь 2026 года текущий стабильный релиз — 26.15.3; новые версии выходят несколько раз в месяц, поэтому фиксируйте версию и проверяйте её перед каждым циклом выпуска. Следующая мажорная версия, v27, находится в стадии альфа по состоянию на июнь 2026 года (ветка 27.0.0-alpha): она переводит electron-builder на нативные ES-модули, повышает минимальную версию среды выполнения до Node.js 22.12 и удаляет давно устаревшие API — поэтому перед переходом на неё проверьте совместимость с Node и конфигурацией. Стабильная ветка пока остаётся 26.x. Многие команды выбирают electron-builder именно из-за встроенного механизма обновления: это комплексное решение, добавляющее единственную зависимость, самостоятельно управляющее дополнительными требованиями и заменяющее функции, используемые мейнтейнерами Electron, — например, автообновление — собственными реализациями.

В этой статье для примеров конфигурации используется electron-builder, поскольку его декларативный блок в package.json наглядно отображается на каждую целевую платформу, а его компаньон electron-updater является де-факто стандартом для самостоятельно размещаемых обновлений. Концепции переносятся на Forge, если вы предпочитаете официальный путь.

Что насчёт Tauri?

Tauri 2.x — это заслуживающая внимания более лёгкая альтернатива Electron, когда бандл размером ~100 МБ неприемлем. Он отображает пользовательский интерфейс через встроенный WebView операционной системы вместо того, чтобы включать в сборку полноценный Chromium, что даёт значительно меньшие бинарные файлы (разница на порядок, а не в процентах). Компромисс вполне реален: вы теряете единообразие рендеринга Electron на разных машинах и его обширную экосистему npm и нативных модулей, а также сталкиваетесь с фрагментацией версий WebView на разных ОС пользователей. Tauri — правильный выбор для небольшой утилиты с высокими требованиями к безопасности; Electron сохраняет преимущество, когда точность отображения интерфейса и глубина экосистемы важнее размера дистрибутива.

Упаковка для каждой платформы с помощью electron-builder

electron-builder создаёт нативные установщики на основе единственного блока build в package.json. Определите конфигурацию верхнего уровня и ключи mac, win и linux для каждой платформы, указывающие нужные цели (targets). Минимальная мультиплатформенная конфигурация выглядит так:

{
  "build": {
    "appId": "com.example.myapp",
    "productName": "MyApp",
    "directories": { "output": "dist" },
    "files": ["dist-app/**/*", "package.json"],
    "mac": {
      "category": "public.app-category.productivity",
      "target": ["dmg", "zip"],
      "hardenedRuntime": true,
      "notarize": true
    },
    "win": {
      "target": ["nsis"]
    },
    "linux": {
      "target": ["AppImage", "deb", "rpm"],
      "category": "Utility"
    },
    "publish": [{ "provider": "github" }]
  }
}

Каждая цель соответствует реальному формату установщика:

Два нюанса целей electron-builder, на которых часто спотыкаются. Цель zip на macOS не является опциональной при использовании автообновления: цель zip для macOS обязательна для Squirrel.Mac, иначе невозможно создать latest-mac.yml, что вызывает ошибку autoUpdater — а поскольку цель macOS по умолчанию — dmg+zip, явно указывать её обычно не нужно. Для автообновления в частности macOS-приложение должно быть подписано, а поддерживаемые цели по умолчанию — DMG (macOS), AppImage/DEB/Pacman/RPM (Linux) и NSIS (Windows). Запустите сборку командой npx electron-builder --mac --win --linux, но учтите, что полноценную подписанную сборку для конкретной платформы можно создать только на ней (или для неё) — именно поэтому CI так важен.

О базовом уровне безопасности: в этой статье предполагается, что ваше приложение уже работает с рекомендуемыми настройками безопасности Electron — preload-скриптом с включённым contextIsolation и отключённым nodeIntegration. Никогда не выпускайте приложение с обратными настройками; упаковка не исправляет небезопасный рендерер.

Подпись кода и нотаризация: цепочка зависимостей

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

macOS: сначала подпись, затем нотаризация

Вам нужен сертификат Apple Developer ID, для получения которого требуется членство в программе. Apple Developer Program стоит 99 USD в год, с ценами в местной валюте при регистрации — не «EUR99», — а нотаризация включена в стоимость: будучи участником Apple Developer Program, вы можете нотаризировать Mac-приложения без дополнительной оплаты. Нотаризация (автоматическая проверка Apple на наличие вредоносного ПО) обязательна для приложений с Developer ID, распространяемых за пределами Mac App Store, начиная с macOS 10.15 Catalina.

В electron-builder установите hardenedRuntime: true и notarize: true в блоке mac (показано выше), а затем передайте учётные данные через переменные окружения во время сборки — никогда не храните их в репозитории:

# Сертификат подписи macOS (base64-encoded .p12) и его пароль
export CSC_LINK="$(base64 -i developer-id.p12)"
export CSC_KEY_PASSWORD="••••••"
# Учётные данные для нотаризации (App Store Connect API или пароль приложения Apple ID)
export APPLE_ID="you@example.com"
export APPLE_APP_SPECIFIC_PASSWORD="abcd-efgh-ijkl-mnop"
export APPLE_TEAM_ID="XXXXXXXXXX"

Windows: изменения SmartScreen в 2024 году

Начните принятие решений по Windows с изменения, которое упускают почти все устаревшие руководства. EV-сертификаты больше не обходят SmartScreen: раньше подпись с помощью сертификата Extended Validation по умолчанию давала положительную репутацию в SmartScreen, но это поведение больше не существует, и переплачивать за EV исключительно ради обхода предупреждений SmartScreen больше не оправдано. Установщик, подписанный EV-сертификатом, теперь накапливает репутацию загрузок точно так же, как более дешёвый сертификат Organization Validated (OV).

Второе изменение касается места хранения ключей. С 1 июня 2023 года закрытые ключи подписи кода должны храниться на сертифицированном оборудовании — именно поэтому OV-сертификат на USB-токене не работает в безголовом CI. Документация Tauri по подписи для Windows фиксирует ту же границу: их стандартное руководство применимо только к OV-сертификатам, полученным до 1 июня 2023 года, а для сертификатов, полученных после этой даты, они направляют к процессу с аппаратным токеном от издателя.

Наиболее чистый подход в 2026 году полностью обходит эту проблему. Azure Artifact Signing — ранее известный как Trusted Signing — это полностью управляемый сквозной сервис подписи кода, интегрированный с Azure. Он подписывает из облака без USB-токена, нативно работает в CI/CD-конвейерах и хранит ключи в управляемых Microsoft HSM. Используйте следующий порядок принятия решений:

1. В первую очередь — Azure Artifact Signing. Он нативно совместим с CI и недорог (Microsoft документирует тарифные планы на основе потребления в диапазоне ~$10/месяц для небольших проектов). Доступность ограничена организациями в США, Канаде, ЕС и Великобритании; для индивидуальных разработчиков в настоящее время доступен только в США и Канаде.
2. OV-сертификат от DigiCert, Sectigo или GlobalSign, если вы находитесь за пределами этих регионов. OV-сертификаты функционально эквивалентны Azure Artifact Signing с точки зрения SmartScreen.
3. Сохраняйте уже имеющийся EV-сертификат до истечения срока действия — если он у вас уже есть, он по-прежнему действителен и функционален для подписи, хотя переплачивать за EV исключительно ради обхода SmartScreen больше не оправдано. Не покупайте новый по этой причине.

Подписанные vs неподписанные

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

Автообновления с electron-updater

electron-updater (компаньон electron-builder) обеспечивает кросс-платформенные самостоятельно размещаемые обновления с минимальным объёмом кода. Он поддерживает GitHub Releases, Amazon S3, DigitalOcean Spaces, Keygen и произвольный HTTP(S)-сервер из коробки, и для его работы достаточно всего двух строк кода. Типичный случай:

const { autoUpdater } = require("electron-updater");

app.whenReady().then(() => {
  createWindow();
  autoUpdater.checkForUpdatesAndNotify();
});

Вызовите autoUpdater.checkForUpdatesAndNotify() — и не вызывайте setFeedURL, поскольку electron-builder автоматически создаёт внутренний файл app-update.yml при сборке. Место размещения релизов определяется блоком publish в конфигурации сборки; указание { "provider": "github" } означает, что отправка тега запускает CI, загружает артефакты в GitHub Release, и обновлятор находит их автоматически. На macOS эта однострочная конструкция не принесёт пользы, если сборка не подписана и не нотаризована — та же цепочка из предыдущего раздела. В Linux нет универсального механизма автообновления; обновления AppImage работают через electron-updater, но пользователи deb/rpm обновляются через свой пакетный менеджер.

Каналы распространения

Выбирайте каналы исходя из охвата аудитории и того, какую долю дохода и доверия вы хотите сохранить:

• Собственный сайт. Полный контроль, подписанные или неподписанные сборки, без комиссий, и прямая интеграция с electron-updater через GitHub Releases или S3.
• GitHub Releases. Бесплатный хостинг, история версий и наименее трудоёмкий путь для интеграции автообновления.
• Mac App Store. Добавляет возможность обнаружения, но требует песочницы и проверки, а также стандартной комиссии Apple в размере 30% — сниженной до 15% в рамках App Store Small Business Program для разработчиков с годовым доходом менее 1 млн USD.
• Microsoft Store. Стоит рассмотреть хотя бы ради преимущества со SmartScreen: публикация MSIX-пакета через Microsoft Store означает, что Microsoft автоматически переподписывает ваш пакет, поэтому пользователи никогда не увидят предупреждение SmartScreen, а вам не нужно покупать или обновлять сертификат.
• Homebrew Cask. Бесплатное, удобное для разработчиков распространение для macOS через pull request в репозиторий casks — идеально для охвата технической аудитории с помощью brew install.

Практическое замечание, которое стоит иметь в виду: поскольку рендерер Electron — это окно Chromium, инструменты записи сессий браузера работают без изменений в упакованной десктопной сборке. Это один из немногих практических способов наблюдать за регрессиями UI, которые проявляются только после упаковки или автообновления на машине пользователя — пути через нативное меню и системный трей, диалоги выбора файлов, различия CSP в подписанных сборках — и никогда не воспроизводятся при запуске electron . в процессе разработки.

Сборка для всех трёх платформ в CI с помощью GitHub Actions

Кросс-сборку для всех платформ локально выполнить невозможно: нотаризация DMG требует инструментов macOS, а подписанные установщики Windows требуют инструментов Windows. Реалистичный подход в 2026 году — матрица GitHub Actions с раннерами macos-latest, windows-latest и ubuntu-latest, работающими параллельно, с секретами подписи, передаваемыми через зашифрованные переменные окружения. Полный файл release.yml, выполняющий сборку и публикацию по тегу:

name: Release
on:
  push:
    tags: ["v*"]

jobs:
  release:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [macos-latest, windows-latest, ubuntu-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - name: Build, sign, and publish
        run: npx electron-builder --publish always
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # Подпись и нотаризация macOS (считывается только на macos-latest)
          CSC_LINK: ${{ secrets.MAC_CSC_LINK }}
          CSC_KEY_PASSWORD: ${{ secrets.MAC_CSC_KEY_PASSWORD }}
          APPLE_ID: ${{ secrets.APPLE_ID }}
          APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_PASSWORD }}
          APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
          # Windows: учётные данные Azure Artifact Signing (считываются на windows-latest)
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}

Каждый раннер собирает только цели своей платформы, electron-builder выполняет подпись с использованием учётных данных, присутствующих в окружении этого раннера, а --publish always загружает все артефакты вместе с метаданными обновления latest*.yml в единый GitHub Release. Храните все секреты в секретах репозитория или окружения — никогда в файле workflow. Поскольку Azure Artifact Signing работает с GitHub Actions и Azure DevOps через обычные переменные окружения, задание для Windows не требует ни USB-токена, ни самостоятельно размещаемого раннера.

Выпуск Electron-приложения — это не одна магическая команда, а соблюдение цепочки: подпись, чтобы можно было нотаризовать; нотаризация, чтобы автообновление на macOS работало; и запуск всего этого в матрице CI, поскольку ни одна машина не может собрать сборки для всех трёх платформ. Настройте блок build, добавьте electron-updater, зафиксируйте release.yml — и следующая команда git tag v1.0.0 && git push --tags создаст подписанные, поддерживающие обновления установщики для всех платформ одновременно.

Часто задаваемые вопросы

Можно ли собрать подписанные установщики для macOS, Windows и Linux на одной машине?

Нет. Нотаризация DMG требует инструментов macOS, а подписанные установщики Windows требуют инструментов Windows, поэтому ни одна машина не может создать подписанные сборки для всех трёх платформ. Вы можете собирать для той платформы, на которой работаете, и electron-builder поддерживает некоторые варианты кросс-сборки, однако подпись и нотаризация привязаны к платформе. Реалистичный подход в 2026 году — матрица GitHub Actions с раннерами macos-latest, windows-latest и ubuntu-latest, работающими параллельно, где каждый раннер собирает и подписывает только цели своей платформы.

Устраняет ли Microsoft Store предупреждения SmartScreen без сертификата подписи кода?

Да. Публикация MSIX-пакета через Microsoft Store означает, что Microsoft автоматически переподписывает ваш пакет, поэтому пользователи никогда не увидят предупреждение SmartScreen, а вам не нужно покупать или обновлять сертификат. Это делает Microsoft Store эффективным способом полностью избежать затрат на сертификат и процесса накопления репутации. Компромисс — необходимость прохождения проверки в магазине и упаковки приложения в формат MSIX вместо прямого распространения автономного установщика NSIS или MSI с собственного сайта.

Почему моё macOS-приложение уведомляет пользователей об обновлениях, но никогда не устанавливает их автоматически?

Скорее всего, сборка не подписана. На macOS приложение должно быть подписано для работы автоматических обновлений, поскольку этого требует Squirrel.Mac. Неподписанное приложение может обнаружить новую версию и уведомить пользователя, но не может в тихом режиме заменить бинарный файл. Решение — полная цепочка: получите сертификат Apple Developer ID, подпишите приложение, затем нотаризуйте его. Подпись кода — предварительное условие для нотаризации, а нотаризация — предварительное условие для работающего тихого автообновления на macOS.

Стоит ли по-прежнему платить за EV-сертификат, чтобы избежать предупреждений SmartScreen на Windows?

Нет. Ранее EV-сертификаты полностью обходили SmartScreen при первой загрузке, однако Microsoft убрала это поведение мгновенного получения репутации в 2024 году. Установщик, подписанный EV-сертификатом, теперь накапливает репутацию загрузок точно так же, как более дешёвый сертификат Organization Validated, поэтому переплачивать за EV исключительно ради обхода SmartScreen больше не оправдано. Для большинства команд в 2026 году более чистым решением по умолчанию является Azure Artifact Signing, который подписывает из облака без USB-токена, или OV-сертификат, если вы находитесь за пределами поддерживаемых регионов.