Empaquetado y Distribución de Aplicaciones Electron

Llevar una aplicación Electron a usuarios reales es un proceso de cuatro etapas: empaquetar la aplicación en un instalador nativo para cada plataforma, firmar y notarizar para que los sistemas operativos confíen en ella, distribuirla a través de un canal accesible para los usuarios, y configurar las actualizaciones automáticas para mantenerla al día. La herramienta que elijas para gestionar ese proceso es la primera decisión, y en 2026 se reduce a dos opciones: Electron Forge o electron-builder. Esta guía recorre el camino completo con configuraciones listas para copiar y pegar, las reglas de firma de código que cambiaron en 2023 y 2024, y un flujo de trabajo funcional en GitHub Actions con una matriz que compila las tres plataformas en paralelo, porque no es posible compilar todo desde una sola máquina.

Electron Forge vs electron-builder en 2026

Elige Electron Forge si quieres un pipeline todo en uno con soporte oficial; elige electron-builder si prefieres el actualizador automático integrado más maduro y la mayor presencia en la comunidad. Ambos generan instaladores firmados y actualizables para macOS, Windows y Linux. La diferencia radica en el modelo de soporte y la filosofía, no en las capacidades.

Electron Forge es la herramienta respaldada oficialmente por el proyecto. Es una solución todo en uno para empaquetar y distribuir aplicaciones Electron que combina múltiples paquetes de propósito específico en un pipeline de compilación completo y listo para usar, con firma de código, instaladores y publicación de artefactos. Forge absorbió las utilidades anteriores @electron/packager y @electron/osx-sign en su sistema de Makers y Publishers. Cabe destacar que, si no deseas usar Electron Forge, las demás herramientas de terceros son mantenidas por miembros de la comunidad y no cuentan con soporte oficial del proyecto Electron.

electron-builder es esa alternativa comunitaria — y la más descargada, con cifras de entre 2 y 3 millones de instalaciones semanales según la fuente consultada. A junio de 2026, la versión estable actual es la 26.15.3, con nuevas versiones publicadas varias veces al mes, por lo que conviene fijar la versión y revisarla antes de cada ciclo de lanzamiento. La próxima versión mayor, v27, se encuentra en fase alpha a junio de 2026 (la línea 27.0.0-alpha): migra electron-builder a módulos ES nativos, eleva el requisito mínimo de runtime a Node.js 22.12 y elimina APIs que llevaban tiempo deprecadas, por lo que conviene planificar una revisión de Node y de la configuración antes de adoptarla — aunque el canal estable sigue siendo 26.x por ahora. La razón por la que muchos equipos lo prefieren es su actualizador integrado: electron-builder es una solución completa que añade una única dependencia, gestiona internamente los requisitos adicionales y reemplaza funcionalidades utilizadas por los mantenedores de Electron — como el actualizador automático — con implementaciones propias.

Este artículo utiliza electron-builder en sus ejemplos de configuración porque su bloque declarativo en package.json se adapta con claridad a cada plataforma objetivo, y su complemento electron-updater es el estándar de facto para actualizaciones auto-alojadas. Los conceptos son transferibles a Forge si prefieres la ruta oficial.

¿Qué hay de Tauri?

Tauri 2.x es la alternativa más ligera y creíble frente a Electron cuando un bundle de ~100 MB es un factor limitante. Renderiza la interfaz a través del WebView nativo del sistema operativo en lugar de incluir un runtime completo de Chromium, lo que produce binarios significativamente más pequeños (diferencia de un orden de magnitud, no una cifra exacta). El compromiso es real: se pierde la consistencia de renderizado de Electron entre máquinas y su vasto ecosistema de npm y módulos nativos, y se asume la fragmentación de versiones de WebView entre los sistemas operativos de los usuarios. Tauri es la elección correcta para una utilidad pequeña y con requisitos de seguridad estrictos; Electron sigue siendo superior cuando la fidelidad de la interfaz y la profundidad del ecosistema importan más que el tamaño en disco.

Empaquetado por plataforma con electron-builder

electron-builder genera instaladores nativos a partir de un único bloque build en package.json. Define una configuración de nivel superior junto con las claves mac, win y linux que especifican los targets deseados. Una configuración mínima multiplataforma tiene este aspecto:

{
  "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" }]
  }
}

Cada target corresponde a un formato de instalador real:

Hay dos detalles de los targets de electron-builder que suelen causar problemas. El target zip en macOS no es opcional si usas actualizaciones automáticas: el target zip para macOS es obligatorio para Squirrel.Mac; de lo contrario, no se puede generar latest-mac.yml, lo que provoca un error en el autoUpdater — y como el target predeterminado de macOS ya es dmg+zip, normalmente no es necesario especificarlo de forma explícita. Para las actualizaciones automáticas en concreto, la aplicación de macOS debe estar firmada para que funcionen, y los targets predeterminados compatibles son DMG (macOS), AppImage/DEB/Pacman/RPM (Linux) y NSIS (Windows). Ejecuta una compilación con npx electron-builder --mac --win --linux, pero ten en cuenta que solo puedes generar instaladores firmados de una plataforma determinada en (o para) esa plataforma — de ahí la importancia de la integración continua más adelante.

Sobre la línea base de seguridad: este artículo asume que tu aplicación ya funciona con la configuración de seguridad recomendada para Electron — un script preload con contextIsolation habilitado y nodeIntegration deshabilitado. Nunca distribuyas la configuración inversa; el empaquetado no corrige un renderer inseguro.

Firma de código y notarización: la cadena de dependencias

Esta es la regla que arruina más lanzamientos en macOS que cualquier otra cosa: una aplicación de macOS sin firmar puede notificar al usuario que existe una actualización, pero no puede instalarla de forma silenciosa. La firma de código es un requisito previo para la notarización, y la notarización es un requisito previo para que las actualizaciones automáticas en macOS funcionen. La aplicación debe estar firmada para que las actualizaciones automáticas funcionen en macOS — esto es un requisito de Squirrel.Mac. Si se omite la firma, toda la cadena posterior se rompe.

macOS: firmar y luego notarizar

Necesitas un certificado Apple Developer ID, que requiere membresía. El Apple Developer Program cuesta 99 USD por año de membresía, con precios en moneda local durante el proceso de inscripción — no “EUR99”, y la notarización está incluida: una vez que eres miembro del Apple Developer Program, puedes notarizar aplicaciones de Mac sin coste adicional. La notarización (el análisis automatizado de malware de Apple) es obligatoria para las aplicaciones con Developer ID distribuidas fuera de la Mac App Store desde macOS 10.15 Catalina.

En electron-builder, establece hardenedRuntime: true y notarize: true en el bloque mac (como se muestra arriba) y proporciona las credenciales mediante variables de entorno en tiempo de compilación — nunca en el repositorio:

# Certificado de firma de macOS (archivo .p12 codificado en base64) y su contraseña
export CSC_LINK="$(base64 -i developer-id.p12)"
export CSC_KEY_PASSWORD="••••••"
# Credenciales de notarización (API de App Store Connect o contraseña específica de app de Apple ID)
export APPLE_ID="you@example.com"
export APPLE_APP_SPECIFIC_PASSWORD="abcd-efgh-ijkl-mnop"
export APPLE_TEAM_ID="XXXXXXXXXX"

Windows: el cambio de SmartScreen en 2024

Comienza tu decisión sobre Windows con el cambio que casi todas las guías antiguas omiten. Los certificados EV ya no evitan SmartScreen: hace años, firmar con un certificado de Validación Extendida generaba reputación positiva en SmartScreen de forma inmediata, pero ese comportamiento ya no existe, y pagar un precio superior por un certificado EV únicamente para evitar las advertencias de SmartScreen ya no está justificado. Un instalador firmado con EV ahora construye reputación de descarga exactamente igual que uno más económico con Validación de Organización (OV).

El otro cambio tiene que ver con dónde deben residir las claves. Desde el 1 de junio de 2023, las claves privadas de firma de código deben almacenarse en hardware certificado — que es precisamente la razón por la que un certificado OV en token USB no funciona en entornos de CI sin intervención humana. La documentación de firma para Windows de Tauri marca el mismo límite: su guía estándar aplica únicamente a certificados OV adquiridos antes del 1 de junio de 2023, y para los certificados obtenidos después de esa fecha remite al proceso de token de hardware del emisor.

La opción predeterminada más limpia en 2026 evita el token por completo. Azure Artifact Signing — anteriormente conocido como Trusted Signing — es un servicio de firma de código completamente gestionado e integrado con Azure. Firma desde la nube sin necesidad de token USB, funciona de forma nativa en pipelines de CI/CD y almacena las claves en HSMs gestionados por Microsoft. Sigue este orden de decisión:

1. Azure Artifact Signing primero. Es nativo para CI y económico (Microsoft documenta planes de consumo en torno a ~$10/mes para proyectos pequeños). La disponibilidad está limitada a organizaciones en EE. UU., Canadá, la UE y el Reino Unido, mientras que los desarrolladores individuales están actualmente limitados a EE. UU. y Canadá.
2. Certificado OV de DigiCert, Sectigo o GlobalSign si estás fuera de esas regiones. Los certificados OV son funcionalmente equivalentes a Azure Artifact Signing en lo que respecta a SmartScreen.
3. Mantén un certificado EV que ya tengas hasta que caduque — si ya dispones de un certificado EV, sigue siendo válido y funcional para firmar, aunque pagar el precio adicional del EV únicamente para evitar las advertencias de SmartScreen ya no está justificado. No compres uno nuevo por esa razón.

Firmado vs sin firmar

Las compilaciones sin firmar son aceptables para un público técnico familiarizado con los pasos para omitir la advertencia. Para usuarios no técnicos — y para cualquier aplicación que se actualice automáticamente en macOS — la firma es innegociable.

Actualizaciones automáticas con electron-updater

electron-updater (el complemento de electron-builder) ofrece actualizaciones auto-alojadas multiplataforma con un código mínimo. Es compatible con GitHub Releases, Amazon S3, DigitalOcean Spaces, Keygen y un servidor HTTP(S) genérico de forma nativa, y solo necesita dos líneas de código para funcionar. El caso más habitual:

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

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

Llama a autoUpdater.checkForUpdatesAndNotify() — y no llames a setFeedURL, porque electron-builder genera automáticamente un archivo interno app-update.yml durante la compilación. El lugar donde se alojan las releases se define en el bloque publish de la configuración de compilación; apuntarlo a { "provider": "github" } significa que al publicar un tag se activa el CI, se suben los artefactos a una GitHub Release y el actualizador los encuentra automáticamente. En macOS, esta línea no tiene ningún efecto útil si la compilación no está firmada y notarizada — la misma cadena de la sección anterior. Linux no tiene un mecanismo universal de actualización automática; las actualizaciones de AppImage funcionan a través de electron-updater, pero los usuarios de deb/rpm actualizan a través de su gestor de paquetes.

Canales de distribución

Elige los canales según el alcance de tu audiencia y cuánto control sobre los ingresos y la confianza quieres mantener:

• Tu propio sitio web. Control total, firmado o sin firmar, sin comisión, y se integra directamente con electron-updater a través de GitHub Releases o S3.
• GitHub Releases. Alojamiento gratuito, historial de versiones y el camino de menor resistencia para la integración con actualizaciones automáticas.
• Mac App Store. Añade visibilidad, pero requiere sandboxing y revisión, y aplica la comisión estándar del 30% de Apple — reducida al 15% mediante el App Store Small Business Program para desarrolladores con ingresos anuales inferiores a 1 millón de USD.
• Microsoft Store. Vale la pena solo por la ventaja con SmartScreen: publicar un paquete MSIX a través de la Microsoft Store significa que Microsoft re-firma tu paquete automáticamente, por lo que los usuarios nunca ven una advertencia de SmartScreen y tú nunca necesitas comprar ni renovar un certificado.
• Homebrew Cask. Distribución gratuita y orientada a desarrolladores para macOS mediante un pull request al repositorio de casks — ideal para llegar a usuarios técnicos con brew install.

Una nota práctica que conviene tener en cuenta: dado que el renderer de Electron es una ventana de Chromium, la instrumentación de reproducción de sesiones del navegador funciona sin modificaciones en una compilación de escritorio empaquetada, lo que representa una de las pocas formas prácticas de observar regresiones de interfaz que solo aparecen tras el empaquetado o una actualización automática en la máquina del usuario — rutas de menú nativo y bandeja del sistema, flujos de diálogos de archivo, diferencias de CSP en compilaciones firmadas — y que nunca se manifiestan durante el desarrollo con electron ..

Compilación de las tres plataformas en CI con GitHub Actions

No es posible compilar todo de forma local para todas las plataformas: la notarización de DMG requiere herramientas de macOS, y los instaladores firmados de Windows requieren herramientas de Windows. El enfoque más realista en 2026 es una matriz de GitHub Actions con macos-latest, windows-latest y ubuntu-latest en paralelo, inyectando los secretos de firma como variables de entorno cifradas. Un release.yml completo que compila y publica al crear un tag:

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 }}
          # Firma + notarización de macOS (se lee solo en 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: credenciales de Azure Artifact Signing (se leen en windows-latest)
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}

Cada runner compila únicamente los targets de su propia plataforma, electron-builder firma utilizando las credenciales presentes en el entorno de ese runner, y --publish always sube todos los artefactos junto con los metadatos de actualización latest*.yml a una única GitHub Release. Almacena todos los secretos en los secretos del repositorio o del entorno — nunca en el archivo del workflow. Dado que Azure Artifact Signing funciona con GitHub Actions y Azure DevOps a través de variables de entorno simples, el job de Windows no necesita token USB ni runner auto-alojado.

Distribuir una aplicación Electron no se trata de un único comando mágico, sino de respetar la cadena: firmar para poder notarizar, notarizar para que las actualizaciones automáticas en macOS funcionen, y ejecutar todo en una matriz de CI porque ninguna máquina puede compilar las tres plataformas. Configura el bloque build, añade electron-updater, confirma un release.yml, y tu próximo git tag v1.0.0 && git push --tags generará instaladores firmados y actualizables para todas las plataformas a la vez.

Preguntas Frecuentes

¿Puedo compilar instaladores firmados para macOS, Windows y Linux en una sola máquina?

No. La notarización de DMG requiere herramientas de macOS y los instaladores firmados de Windows requieren herramientas de Windows, por lo que ninguna máquina puede generar compilaciones firmadas para las tres plataformas. Puedes compilar para la plataforma en la que estás trabajando, y electron-builder admite cierta compilación cruzada, pero la firma y la notarización están vinculadas a la plataforma. El enfoque más realista en 2026 es una matriz de GitHub Actions con macos-latest, windows-latest y ubuntu-latest en paralelo, donde cada runner compila y firma únicamente los targets de su propia plataforma.

¿La Microsoft Store elimina las advertencias de SmartScreen sin necesidad de un certificado de firma de código?

Sí. Publicar un paquete MSIX a través de la Microsoft Store significa que Microsoft re-firma tu paquete automáticamente, por lo que los usuarios nunca ven una advertencia de SmartScreen y tú nunca necesitas comprar ni renovar un certificado. Esto convierte a la Microsoft Store en una forma efectiva de evitar tanto los costes de certificados como el proceso de construcción de reputación. La contrapartida es el proceso de envío y revisión de la tienda, y el requisito de empaquetar la aplicación como MSIX en lugar de distribuir un instalador NSIS o MSI directamente desde tu propio sitio.

¿Por qué mi aplicación de macOS notifica a los usuarios sobre actualizaciones pero nunca las instala automáticamente?

La compilación casi con certeza no está firmada. En macOS, una aplicación debe estar firmada para que las actualizaciones automáticas funcionen, ya que Squirrel.Mac lo exige. Una aplicación sin firmar puede detectar y notificar al usuario que existe una nueva versión, pero no puede reemplazar el binario de forma silenciosa. La solución es la cadena completa: obtener un certificado Apple Developer ID, firmar la aplicación y luego notarizarla. La firma de código es un requisito previo para la notarización, y la notarización es un requisito previo para que las actualizaciones silenciosas en macOS funcionen.

¿Sigue valiendo la pena pagar por un certificado EV para evitar las advertencias de SmartScreen en Windows?

No. Los certificados EV anteriormente evitaban SmartScreen por completo en la primera descarga, pero Microsoft eliminó ese comportamiento de reputación instantánea en 2024. Un instalador firmado con EV ahora construye reputación de descarga exactamente igual que un certificado de Validación de Organización más económico, por lo que pagar el precio adicional del EV únicamente para evitar SmartScreen ya no está justificado. Para la mayoría de los equipos en 2026, la opción predeterminada más adecuada es Azure Artifact Signing, que firma desde la nube sin necesidad de token USB, o un certificado OV si estás fuera de las regiones elegibles.