Canales

Un canal de actualización en vivo apunta a una construcción específica de paquete JS de tu aplicación que se compartirá con cualquier dispositivo configurado para escuchar ese canal de actualizaciones. Cuando instales el canal de actualización en vivo Capgo SDK en tu aplicación, cualquier binario nativo configurado a ese canal verificará actualizaciones disponibles cada vez que se lance la aplicación. Puedes cambiar la construcción a la que apunta el canal en cualquier momento y también puedes retroceder a versiones anteriores si es necesario.

Los canales no proporcionan confidencialidad

Los canales controlan la elegibilidad de actualizaciones, no la secrecía de paquetes. Incluso si un canal es privado o se ha deshabilitado la autoasignación, cualquier paquete no cifrado cargado a Capgo debe tratarse todavía como un activo público entregado a los clientes. La cifrado protege el camino de entrega y la autenticidad de las actualizaciones, pero los paquetes enviados todavía pueden ser descompuestos con suficiente esfuerzo porque la clave pública es parte del cliente. Consulte La cifrado de actualizaciones en vivo para obtener detalles.

Cómo un dispositivo elige un canal (precedencia)

Cuando un dispositivo busca una actualización, Capgo decide qué canal usar en este orden estricto (prioridad más alta primero):

1. Asignación forzada de dispositivo (Panel de control) – Asignar manualmente un ID de dispositivo específico a un canal. Utilice para depuración urgente o pruebas controladas con un solo usuario real. Esto siempre gana.
2. Supervisión de nube (por dispositivo) a través del Panel de control o API – Creado cuando cambia el canal del dispositivo en el panel de control o a través de API. Utilice para usuarios de QA que cambian entre canales de características o PR o para reproducir un problema de usuario. Reinstalar el binario no elimina la entrada; eliminar la entrada del dispositivo sí.

Cambio Instantáneo de Canal con setChannel()

A partir de la versión del plugin 5.34.0, 6.34.0, 7.34.0 o 8.0.0 (dependiendo de tu versión principal), setChannel() funciona de manera diferente: se contacta con el backend para validar que el canal esté permitido (verificando si la autoasignación está habilitada para ese canal), luego se almacena el canal localmente en el dispositivo como defaultChannelEsto significa que el nuevo canal surte efecto instantáneamente para la próxima verificación de actualizaciones—sin necesidad de esperar a la replicación.

Anteriormente, setChannel() guardó la sobrescritura del canal en la base de datos del backend (como Dashboard o API cambios), y los dispositivos tuvieron que esperar a que se replicara la información (hasta 2 minutos) antes de que se reconociera el nuevo canal. El nuevo comportamiento solo lee desde el backend (para la validación) y almacena localmente, lo que hace que los cambios de canal sean instantáneos.

Nota: Even si un canal se vuelve inadecuado después de haberse establecido localmente, el backend aún validará el canal durante las comprobaciones de actualización, por lo que se mantiene la seguridad.

Importante: Cuando se realizan cambios de canal a través de la consola de Dashboard o API, todavía hay un retraso de replicación de hasta 2 minutos antes de que todos los servidores de borde reflejen el cambio. Para un cambio de canal instantáneo, utilice setChannel() desde tu aplicación code—valida con el backend, luego establece el canal localmente para un efecto inmediato.

3. Capacitor de configuración defaultChannel (versión de prueba predeterminada) – Si está presente en capacitor.config.* y no existe una fuerza/override, la aplicación arranca en este canal (por ejemplo, ). beta, qa, pr-123Intendido para versiones de prueba / builds internos para que los probadores aterricen en un canal de pre-lanzamiento automáticamente. Los builds de producción suelen dejar esto sin establecer.
4. Canal predeterminado de Cloud (ruta principal ~99% de usuarios) – Si marca un canal por defecto en la consola, todos los usuarios finales normales (sin fuerza, sin sobrescritura, sin configuración predeterminada de canal) se unen aquí. Cambiarlo para desplegar o retroceder instantáneamente—sin nuevo binario. Si tiene valores predeterminados específicos de plataforma (por ejemplo, uno solo para iOS, uno solo para Android, uno solo para Electron), cada dispositivo se dirige al valor predeterminado que coincida con su plataforma. Dejar el valor predeterminado de la nube sin establecer es permitido; en ese caso, el dispositivo debe coincidir con los pasos 1–3 para recibir actualizaciones.

Buena práctica:

• Trate 1–3 como capas de excepción / pruebas; cuando establezca un valor predeterminado de nube, los usuarios reales deben fluir hacia él. Si no elige establecer uno, sea deliberado sobre cómo los usuarios se unen (normalmente a través de defaultChannel en la configuración o por sobrescripciones por dispositivo).
• Solo configure defaultChannel en binarios que envíe explícitamente a los probadores. Dejarlo sin establecer mantiene la lógica de producción centralizada en la consola.
• Utilice setChannel() con moderación en producción—principalmente para pruebas de QA o diagnósticos dirigidos.

Si un canal está deshabilitado para la plataforma (iOS/Android/Electron) cuando de lo contrario sería elegido, el proceso de selección lo ignora y continúa por la lista.

Resumen: Fuerza > Sobrescritura > Config defaultChannel > Valor predeterminado de la nube.

Comportamiento del canal predeterminado

Establecer un valor predeterminado en la nube es opcional, pero suele servir como ruta de escape para dispositivos nuevos. Sin uno, solo los dispositivos que coincidan con las asignaciones forzadas, las sobrescripciones o un defaultChannel en la configuración Capacitor recibirán actualizaciones. Cuando elijas marcar valores predeterminados, ten en cuenta estos patrones:

• Valor predeterminado único (más común) – Si un canal tiene habilitado iOS, Android y Electron, se convierte en el valor predeterminado único; cualquier dispositivo sin sobrescripciones se unirá aquí.
• Valores predeterminados específicos de plataforma – Si divide los canales por plataforma (por ejemplo, ios-production con solo iOS habilitado, android-production con solo Android habilitado, y electron-production con solo Electron habilitado), marca cada uno como el valor predeterminado para su plataforma. Los dispositivos iOS van a la configuración predeterminada de iOS, los dispositivos Android van a la configuración predeterminada de Android y las aplicaciones Electron van a la configuración predeterminada de Electron.

Recuerda que el valor predeterminado de la nube y defaultChannel en capacitor.config.* ambos ocupan la misma capa de decisión. Si estableces un valor por defecto en la nube, no necesitas duplicar el valor en tu Capacitor configuración—deja defaultChannel vacío para compilaciones de producción. Reserve defaultChannel para binarios que envíes intencionalmente a los probadores o QA cuando desees que comiencen en un canal no de producción, incluso si el valor por defecto en la nube es diferente.

Puedes cambiar los valores por defecto en cualquier momento en la consola. Cuando cambies un valor por defecto, los dispositivos nuevos obedecen las nuevas rutas de inmediato y los dispositivos existentes siguen las reglas de precedencia normales la próxima vez que se conecten.

Configuración de un Canal

Durante la onboarding creas el primer canal (la mayoría de los equipos lo llaman “Producción”), pero nada está bloqueado—puedes renombrar o eliminar cualquier canal en cualquier momento. Para agregar canales adicionales más tarde:

1. Ve a la sección “Canales” de la consola Capgo
2. Haz clic en el botón “Nuevo Canal”
3. Ingresa un nombre para el canal y haz clic en “Crear”

Los nombres de los canales pueden ser cualquier cosa que desees. Una estrategia común es que los canales se ajusten a las etapas de desarrollo, como:

• Development - para probar actualizaciones en vivo en dispositivos locales o emuladores
• QA - para que su equipo de QA verifique actualizaciones antes de una mayor liberación
• Staging - para la prueba final en un entorno de producción similar
• Production - para la versión de su aplicación que los usuarios finales reciben desde las tiendas de aplicaciones

Configuración del Canal en Su Aplicación

Con los canales creados, necesita configurar su aplicación para escuchar el canal apropiado. En este ejemplo, usaremos el Development canal.

Abra su capacitor.config.ts (o capacitor.config.json) archivo. Bajo la plugins sección, establezca opcionalmente defaultChannel para pruebas de compilación (internas / QA). Para compilaciones de producción, prefiere omitirla para que los dispositivos utilicen el valor por defecto de Cloud a menos que se sobrescriba explícitamente.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

A continuación, compile su aplicación web y ejecute npx cap sync para copiar el archivo de configuración actualizado a sus proyectos de iOS, Android y Electron. Si omite este paso de sincronización, sus proyectos nativos seguirán utilizando el canal en el que estaban configurados anteriormente.

Advertencia

Orden de selección de canal: Obligatorio > Sobreescritura (setChannel / panel de control) > Configuración defaultChannel > Valor por defecto de Cloud.

Utilice defaultChannel solo en compilaciones de prueba/internas; déjelo fuera para la producción para que los usuarios sigan el valor por defecto de Cloud (si está configurado) en lugar de duplicar la configuración de ruteo en la configuración nativa.

Puede forzar (fijar) un dispositivo o aplicar un override más tarde—esos lo superan inmediatamente al valor de configuración.

Los nombres de los canales son sensibles a mayúsculas y minúsculas.

Opciones y estrategias de canales

Los canales tienen varias opciones que controlan quién puede recibir actualizaciones y cómo se entregan las actualizaciones. Los más importantes están a continuación. Puede configurar estos desde la aplicación web, el CLI, o el Public API.

• Canales predeterminados: Opcionalmente marque los canales o plataformas específicos que los nuevos dispositivos se unen a. Consulte “Comportamiento de canal predeterminado” para escenarios de enrutamiento.
• Filtros de plataforma: Habilitar o deshabilitar la entrega a dispositivos iOS, Android, o Electron dispositivos por canal.
• Deshabilitar la actualización automática bajo nativo: Evita enviar una actualización cuando la versión nativa del dispositivo es más nueva que la versión de paquete del canal (por ejemplo, dispositivo en 1.2.3 mientras que el canal tiene 1.2.2).
• Permitir actualizaciones de compilaciones de desarrollo: Permitir actualizaciones a compilaciones de desarrollo (útil para la prueba).
• Permitir dispositivos de emulación: Permitir actualizaciones a emuladores/simuladores (útil para la prueba).
• Permitir la autoasignación de dispositivos: permite que la aplicación cambie a este canal en tiempo de ejecución utilizando setChannel. Si se deshabilita, setChannel fallará para este canal.

Deshabilitar estrategias de actualización automática

Utilice esto para restringir qué tipos de actualizaciones entregará automáticamente el canal. Opciones:

• mayor: Bloquear actualizaciones cruzadas de mayor versión (0.0.0 → 1.0.0). Se permiten actualizaciones menores y parches.
• menor: Bloquear actualizaciones cruzadas de versión menor (por ejemplo, 1.1.0 → 1.2.0) y mayores. Se permiten actualizaciones de parches. Nota: no bloquea 0.1.0 → 1.1.0.
• parche: Muy estricto. Sólo permite aumentar versiones de parche dentro del mismo mayor y menor. Ejemplos: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• metadata: Requiere una versión mínima de actualización de metadatos en cada paquete. Configure mediante CLI usando --min-update-version o --auto-min-update-version. Si falta, el canal se marca como configurado incorrectamente y las actualizaciones serán rechazadas hasta que se establezca.
• none: Permitir todas las actualizaciones según compatibilidad de semver.

Obtenga más detalles y ejemplos en la estrategia de deshabilitar actualizaciones en /docs/cli/commands/#disable-updates-strategy.

Ejemplo (CLI):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

Usando setChannel() desde Tu Aplicación

El setChannel() El método permite a tu aplicación cambiar canales de manera programática en tiempo de ejecución. Esto es particularmente útil para:

• Menús de QA/debugeo donde los probadores pueden cambiar entre canales
• Flujos de inscripción de programa beta
• Implementaciones de banderas de características
• Escenarios de prueba A/B

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

¿Cómo funciona setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)?

Cuándo setChannel() se llama:

1. Validación de backend (solo lectura): Se envía una solicitud al backend de Capgo para validar que el canal está permitido (verificando permisos de autoasignación)
2. Actualización de almacenamiento local: Si la validación es exitosa, el canal se guarda en el almacenamiento local del dispositivo como defaultChannel
3. Efecto inmediato: La próxima verificación de actualizaciones utiliza el nuevo canal de inmediato (sin esperar a la replicación)

Por qué esto importa: En versiones anteriores, setChannel() almacenaba el override del canal en la base de datos del backend (igual que los cambios en la consola o API). Los dispositivos tenían que esperar a que se replicara el backend (hasta 2 minutos) antes de que el cambio de canal surtiera efecto. Ahora, setChannel() solo lee del backend (para validación) y almacena localmente, lo que hace que los cambios de canal sean instantáneos.

Nota de seguridad: Incluso si los permisos de un canal cambian después de haberse configurado localmente (por ejemplo, la autoasignación está deshabilitada), el backend aún validará el canal durante las comprobaciones de actualización, asegurando que la seguridad se mantenga.

Comparación de métodos de cambio de canal:

Método	Tiempo de efecto	Persistido en	Uso
setChannel() desde plugin	Instantáneo	Solo dispositivo (local)	Cambiar canal iniciado por el usuario en la aplicación
Ocultar dispositivo en la consola	Hasta 2 min	Base de datos de backend	Cambios administrados para dispositivos específicos
API Asignación de canal	Hasta 2 min	Base de datos de backend	Integraciones de backend automatizadas

Para la mejor experiencia del usuario al crear interfaces de usuario de cambio de canal, siempre utilice el plugin setChannel() método.

Versión mínima para el canal de solo uso local: 5.34.0, 6.34.0, 7.34.0, o 8.0.0 (dependiendo de tu versión principal). Cada número de versión menor corresponde al mismo conjunto de características en todas las versiones principales (por ejemplo, X.34.0 incluye las mismas características, ya sea X 5, 6, 7 o 8). Consulte instalación de plugin para etiquetas de versión.

Asignar un paquete a un canal

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

npx @capgo/cli@latest bundle upload --channel=Development

Este comando subirá tus activos web compilados y establecerá el nuevo paquete como la construcción activa para el Development cualquier aplicación configurada para escuchar ese canal recibirá la actualización la próxima vez que la busque.

También puede asignar compilaciones a canales desde la sección “Paquetes” del panel de control Capgo. Haga clic en el icono de menú junto a una compilación y seleccione “Asignar a Canal” para elegir el canal para esa compilación.

Versión de Paquetes y Canales

Es importante tener en cuenta que los paquetes en Capgo son globales para tu aplicación, no específicos de canales individuales. El mismo paquete puede asignarse a múltiples canales.

Al versionar tus paquetes, recomendamos utilizar la versión semántica semver con identificadores de versión prelanzamiento para compilaciones específicas de canales. Por ejemplo, una versión beta podría versionarse como 1.2.3-beta.1.

Esta aproximación tiene varios beneficios:

• Comunica claramente la relación entre compilaciones. 1.2.3-beta.1 es obvio que es una versión prelanzamiento de 1.2.3.
• Permite reutilizar números de versión en diferentes canales, reduciendo la confusión.
• Permite caminos de rollback claros. Si necesita retroceder desde 1.2.3, sabe 1.2.2 es la versión de lanzamiento estable anterior.

Aquí tienes un ejemplo de cómo podrías alinear las versiones de tu paquete con un conjunto de configuración típico de canal:

• Development canal: 1.2.3-dev.1, 1.2.3-dev.2, etc.
• QA canal: 1.2.3-qa.1, 1.2.3-qa.2, etc.
• Staging canal: 1.2.3-rc.1, 1.2.3-rc.2, etc.
• Production canal: 1.2.3, 1.2.4, etc.

Usar semver con identificadores de pre-lanzamiento es un enfoque recomendado, pero no estrictamente requerido. La clave es encontrar un esquema de versionado que comunique claramente las relaciones entre tus compilaciones y se alinee con el proceso de desarrollo de tu equipo.

Revertir una Actualización en Vivo

Si despliegas una actualización en vivo que introduce un error o necesita ser revertida, puedes revertir fácilmente a una compilación anterior. Desde la sección “Canales” de la consola:

1. Haz clic en el nombre del canal que deseas revertir
2. Encuentra la compilación que deseas revertir y haz clic en el icono de la corona
3. Confirmar la acción

La compilación seleccionada se convertirá inmediatamente en la compilación activa para ese canal. Las aplicaciones recibirán la versión revertida la próxima vez que revisen actualizaciones.

Automatizar Despliegues

Para flujos de trabajo más avanzados, puedes automatizar tus despliegues de actualizaciones en vivo como parte de tu pipeline CI/CD. Al integrar Capgo en tu proceso de compilación, puedes subir automáticamente nuevos paquetes y asignarlos a canales cada vez que envíes cambios a ciertas ramas o crees nuevas versiones.

Echa un vistazo a la Integración de CI/CD documentación para aprender más sobre la automatización de Capgo actualizaciones en vivo.

Desplegar a un Dispositivo

Ahora que entiendes los canales, estás listo para empezar a desplegar actualizaciones en vivo a dispositivos reales. El proceso básico es:

1. Instale el Capgo SDK en su aplicación
2. Configure la aplicación para escuchar su canal deseado
3. Suba una compilación y asigne ese canal
4. Lanzar la aplicación y espere a que se actualice!

Para una guía detallada, consulte la Actualizaciones en Vivo guide. ¡Feliz actualización!

Uso avanzado de canales: segmentación de usuarios

Los canales se pueden utilizar para más que solo las etapas de desarrollo. Son una herramienta poderosa para la segmentación de usuarios, lo que permite características como:

• Banderas de características para diferentes niveles de usuarios
• Pruebas A/B
• Despliegues graduales de características
• Programas de pruebas beta

Aprende a implementar estos casos de uso avanzados en nuestra guía: Cómo segmentar usuarios por plan y canales para banderas de características y pruebas A/B.