Canales

A un canal de Actualizaciones en vivo se 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 instalas las __CAPGO_KEEP_0__ Actualizaciones en vivo __CAPGO_KEEP_1__ en tu aplicación, cualquier binario nativo configurado para ese canal verificará actualizaciones disponibles cada vez que se lance la aplicación. Puedes cambiar la construcción a la que se apunta un canal en cualquier momento y también puedes retroceder a versiones anteriores si es necesario. install the Capgo Live Updates SDK No Proporcionan Confidencialidad

la cifrado de Actualizaciones en vivo

Channels control update eligibility, not bundle secrecy. Even if a channel is private or self-assignment is disabled, any unencrypted bundle uploaded to Capgo should still be treated as a public asset delivered to clients. Encryption protects the delivery path and authenticity of updates, but shipped bundles can still be reverse engineered from the distributed app with enough effort because the public key is part of the client. See ¿Cómo un dispositivo elige un canal (precedencia)? Sección titulada “¿Cómo un dispositivo elige un canal (precedencia)?”

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

When a device checks for an update, Capgo decides which channel to use in this strict order (highest priority first):

1. Forced device mapping (Dashboard) – Pinar manualmente un ID de dispositivo específico a un canal. Utilice para depuración urgente o pruebas controladas con un solo usuario real. Siempre gana.
2. Supervisión de nube (por dispositivo) a través de la consola o API – Se crea cuando cambias el canal del dispositivo en la consola 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 este valor; eliminar la entrada de dispositivo sí.
3. Plugin setChannel() canal local – Se crea cuando la aplicación llama setChannel() y el backend valida que el canal objetivo permite la asignación automática. El canal seleccionado se almacena localmente en ese dispositivo, tiene efecto instantáneo y no se muestra en la interfaz de usuario de Sustitución de Canal.

Intercambio de canales instantáneo con setChannel()

Desde 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 verificar que el canal está permitido (comprobando si la autoasignación está habilitada para ese canal), luego almacena el canal localmente en el dispositivo como . Esto significa que el nuevo canal tiene efecto defaultChannelinstantáneamente para la próxima verificación de actualizaciones—sin necesidad de esperar a la replicación. Anteriormente,

guardaba el sobreescribir de canal en la base de datos del backend (como Dashboard o __CAPGO_KEEP_0__ cambios), y los dispositivos tenían que esperar a la replicación de datos (hasta 2 minutos) antes de que el nuevo canal fuera reconocido. El nuevo comportamiento solo lee de la base de datos del backend (para la validación) y almacena localmente, lo que hace que los cambios de canal sean instantáneos. setChannel() saved the channel override to the backend database (like Dashboard or API changes), and devices had to wait for data replication (up to 2 minutes) before the new channel was recognized. The new behavior only reads from the backend (for validation) and stores locally, making channel switches instant.

es solo local, no hace setChannel() que haga Crear una entrada de dispositivo de sobrescritura en la consola Capgo. La interfaz de usuario de la sobrescritura de dispositivo solo muestra sobrescripciones creadas desde la consola o la Public API.

Nota: Even if a channel becomes disallowed after being set locally, the backend will still validate the channel during update checks, so security is maintained.

Importante: When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() desde su aplicación code—valida con el backend, luego establece el canal localmente para un efecto inmediato.

4. Capacitor config defaultChannel (edición de prueba por defecto) – Si está presente en capacitor.config.* y no existe un canal de fuerza/override/local, la aplicación arranca en este canal (por ejemplo, beta, qa, pr-123Intendido para ediciones de prueba / internas para que los probadores aterricen en un canal de pre-lanzamiento automáticamente. Las ediciones de producción suelen dejar esto sin establecer.
5. 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 de la consola/API, sin canal local de plugin, sin configuración por defecto de canal) se unen aquí. Cambiarlo a un lanzamiento o retroceso instantáneo—sin nuevo binario. Si tiene valores por defecto específicos de plataforma (por ejemplo, uno solo para iOS, uno solo para Android, uno solo para Electron), cada dispositivo aterriza en el valor por defecto que coincide con su plataforma. Dejar el valor por defecto de la nube sin establecer es permitido; en ese caso, el dispositivo debe coincidir en los pasos 1–4 para recibir actualizaciones.

Buena práctica:

• Trate a 1–4 como capas de excepción / pruebas; cuando establezca un valor por defecto de la 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 la configuración o las 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.
• Use 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 se elegiría, el proceso de selección lo omite y continúa hacia abajo en la lista.

Resumen: Fuerza > Sobrescritura de la consola/API > Canal local de plugin > Config setChannel() > Valor por defecto de la nube. defaultChannel Best practice: Use sparingly in production—mainly for QA or targeted diagnostics. If a channel is disabled for the platform (iOS/Android/Electron toggles) when it would otherwise be chosen, the selection process skips it and continues down the list. Only configure in binaries you explicitly ship to testers. Leaving it unset keeps production logic centralized in the dashboard. Treat 1–4 as exception / testing layers; when you set a cloud default, real users should flow into it. If you choose not to set one, be deliberate about how users attach (typically via config or per-device overrides). – Si marca un canal por defecto en la consola, todos los usuarios finales normales (sin fuerza, sin sobrescritura de la consola/__CAPGO_KEEP_0__, sin canal local de plugin, sin configuración por defecto de canal) se unen aquí. Cambiarlo a un lanzamiento o retroceso instantáneo—sin nuevo binario. Si tiene valores por defecto específicos de plataforma (por ejemplo, uno solo para iOS, uno solo para Android, uno solo para Electron), cada dispositivo aterriza en el valor por defecto que coincide con su plataforma. Dejar el valor por defecto de la nube sin establecer es permitido; en ese caso, el dispositivo debe coincidir en los pasos 1–4 para recibir actualizaciones. Summary: Force > Dashboard/__CAPGO_KEEP_0__ Override > Plugin local channel > Config > Cloud Default.

Comportamiento de canal por defecto

Establecer un valor por defecto en la nube es opcional, pero suele servir como ruta de respaldo para nuevos dispositivos. 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 por defecto, ten en cuenta estos patrones:

• Valor por defecto único (más común) – Si un canal tiene habilitado iOS, Android y Electron, se convierte en el valor por defecto único; cualquier dispositivo sin sobrescripciones se unirá aquí.
• Valores por defecto 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 por defecto para su plataforma. Los dispositivos iOS van a la configuración por defecto de iOS, los dispositivos Android van a la configuración por defecto de Android y las aplicaciones Electron van a la configuración por defecto de Electron.

Recuerda que el valor por defecto de la nube y defaultChannel In ambas ocupan el mismo nivel de decisión. Si estableces un valor por defecto en la nube, no necesitas duplicar el valor en tu __CAPGO_KEEP_0__ configuración—deja capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel para binarios que envíes intencionalmente a los probadores o QA cuando desees que comiencen en un canal no de producción aunque el valor por defecto de la nube sea diferente. defaultChannel 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

Sección titulada “Configuración de un Canal”

Vaya a la sección “Canales” de la consola __CAPGO_KEEP_0__

1. Go to the “Channels” section of the Capgo dashboard
2. Introduzca un nombre para el canal y haga clic en “Crear”
3. 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:

Setting up a Channel

• Development - para probar actualizaciones en vivo en dispositivos locales o emuladores
• QA - para que su equipo de QA verifique las 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 la aplicación que los usuarios finales reciben desde las tiendas de aplicaciones

Configurando el Canal en Tu Aplicación

Una vez creados los canales, debes configurar tu aplicación para escuchar el canal adecuado. En este ejemplo, utilizaremos el Development canal.

Abre tu capacitor.config.ts (o capacitor.config.json) archivo. En la sección plugins opcionalmente establece defaultChannel para pruebas de compilación (interna / QA). Para compilaciones de producción, prefiere omitirlo para que los dispositivos utilicen el valor por defecto de Cloud a menos que se haya sobrescrito 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 salta este paso de sincronización, sus proyectos nativos seguirán utilizando el canal en el que estaban configurados anteriormente.

Advertencia

El orden de selección de canales: Obligatorio > Dashboard/API dispositivo de sobrescritura > Plugin setChannel() canales locales > Config defaultChannel > Valor por defecto de Cloud.

Utilice defaultChannel solo en compilaciones internas de prueba; omitirlo para producción para que los usuarios sigan el valor predeterminado de Cloud (si está configurado) en lugar de duplicar la configuración de routing en la configuración nativa.

Todavía puedes forzar (fijar) un dispositivo o aplicar un override más tarde—esos superan inmediatamente el valor de configuración.

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

Opciones y estrategias de canal

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. Puedes configurar estos desde la aplicación web, el CLI, o el API público.

• Canal predeterminado: Opcionalmente marca los canales o las configuraciones de plataforma que los nuevos dispositivos se unen a. Consulta “Comportamiento del canal predeterminado” para escenarios de routing.
• Filtros de plataforma: Habilita o deshabilita 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 del app nativo 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: Permite actualizaciones a emuladores/simuladores (útil para pruebas).
• Permitir autoasignación de dispositivo: Deja que la aplicación cambie a este canal en tiempo de ejecución utilizando setChannelSi 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: Bloquea un paquete objetivo cuya versión mayor es mayor que la base nativa del dispositivo (version_build). Ejemplo: 1.2.3 -> 2.0.0 está bloqueado; 1.2.3 -> 1.9.0 está permitido.
• menor: Bloquea un paquete objetivo cuya versión mayor o menor difiere de la base nativa del dispositivo ( version_build. Ejemplo: 1.2.3 -> 1.3.0 está bloqueado; 1.2.3 -> 1.2.4 está permitido.
• patch: Modo más estricto. Bloquea cualquier cambio a un número de versión mayor, menor o de parche. Solo se permiten cambios de sufijo mientras MAJOR.MINOR.PATCH se mantiene igual. Ejemplos: 1.0.0-beta.1 -> 1.0.0-beta.2 está permitido, 1.0.0+build.1 -> 1.0.0+build.2 está permitido, 1.0.0 -> 1.0.1 está bloqueado.
• metadata: Requiere una versión de actualización mínima 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 de manera incorrecta y las actualizaciones serán rechazadas hasta que se establezca.
• none: Permitir todas las actualizaciones según compatibilidad de semver.

Estas estrategias comparan el paquete objetivo del canal con la base nativa enviada como version_build, no el paquete descargado actualmente enviado como version_name.

Obtenga más detalles y ejemplos en la estrategia de deshabilitar actualizaciones en /docs/cli/comandos/#desactivar-estrategia-de-actualizaciones.

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() Este método permite que tu aplicación cambie programáticamente entre canales 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 en el 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 defaultChannel
3. Efecto inmediato: La próxima verificación de actualizaciones utiliza el nuevo canal inmediatamente (sin esperar a la replicación)

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

Visibilidad de la consola: Un canal configurado con el plugin no hace que el dispositivo aparezca como una sobrescritura de dispositivo en la consola de Capgo. Solo las asignaciones de canales creadas desde la consola o el Public API se muestran allí. Utilice la consola o API cuando necesite una sobrescritura visible para administradores.

Nota de seguridad: Incluso si los permisos de un canal cambian después de ser configurados localmente (por ejemplo, la autoasignación está deshabilitada), el backend validará el canal durante las verificaciones de actualizaciones, asegurando la seguridad.

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

Método	Tiempo de efecto	Almacenado en	Mostrado en la interfaz de usuario de dispositivo de sobrescritura	Uso de caso
setChannel() desde plugin	Inmediato	Solo dispositivo (local)	No	Cambiar canal iniciado por el usuario en la aplicación
Panel de dispositivo de sobrescritura	Hasta 2 min	Base de datos de servidor	Sí	Cambios iniciados por el administrador para dispositivos específicos
API asignación de canal	Hasta 2 min	Base de datos de backend	Sí	Integraciones de backend automatizadas

Para obtener la mejor experiencia del usuario al crear interfaces de usuario de cambio de canal, siempre utilice el método del plugin. setChannel() Versión mínima para el cambio de canal solo local:

, o 5.34.0, 6.34.0, 7.34.0(dependiendo de su 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 independientemente de que X sea 5, 6, 7 o 8). Consulte la documentación de la versión de GitHub de Capgo. 8.0.0 documentación de la versión de GitHub de Capgo instalación de plugins para etiquetas de versión.

Asignar un paquete a un canal

Para desplegar una actualización en vivo, necesita subir una nueva construcción de paquete de JS y asignarla a un canal. Puede hacer esto en un paso con el Capgo CLI:

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

Esto subirá sus activos web compilados y establecerá el nuevo paquete como la construcción activa para el Development canal. Cualquier aplicación configurada para escuchar ese canal recibirá la actualización la próxima vez que busque una.

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

Versión de paquetes y canales

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

Cuando estés versionando tus paquetes, recomendamos utilizar la versión semántica con Capgo’s Tester de Semver y identificadores de pre-lanzamiento para construcciones específicas de canal. Por ejemplo, un lanzamiento beta podría versionarse como 1.2.3-beta.1.

Esta aproximación tiene varios beneficios:

• Comunica claramente la relación entre construcciones. 1.2.3-beta.1 es obvio que es una pre-construcción de 1.2.3.
• Permite el uso de números de versión repetidos en canales, reduciendo la confusión.
• Habilita caminos de rollback claros. Si necesitas retroceder desde 1.2.3, sabes que 1.2.2 es la versión estable anterior.

Aquí tienes un ejemplo de cómo podrías alinear las versiones de tus paquetes con una configuración de canal típica:

• 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.

Usando semver con identificadores de pre-lanzamiento es un enfoque recomendado, pero no estrictamente necesario. 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 despliega una actualización en vivo que introduce un error o necesita ser revertida, puede revertir fácilmente a una versión anterior. Desde la sección “Canales” de la consola:

1. Click en el nombre del canal que desea revertir
2. Encuentre la versión que desea revertir y haga clic en el icono de corona
3. Confirmar la acción

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

Automatización de Despliegues

Para flujos de trabajo más avanzados, puede automatizar sus despliegues de actualizaciones en vivo como parte de su pipeline CI/CD. Al integrar Capgo en su proceso de compilación, puede subir automáticamente nuevos paquetes y asignarlos a canales cada vez que pulse en ciertas ramas o cree nuevas versiones.

Consulte la Integración CI/CD documentos para aprender más sobre automatizar 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. Instalar el Capgo SDK en tu aplicación
2. Configurar la aplicación para escuchar tu canal deseado
3. Subir una compilación y asignarla a ese canal
4. Ejecutar la aplicación y espera a que se actualice!

Para una guía detallada, consulta el Actualizaciones en Vivo guía. ¡Feliz actualizando!

Uso Avanzado de Canales: Segmentación de Usuarios

Los canales se pueden utilizar para más que solo 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
• Implementación gradual de características
• Programas de pruebas beta

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

Sigue adelante desde Canales

Si está utilizando Canales para planificar la ruta de canal y la implementación escalonada, conecte con Canales para los detalles de implementación en Canales, Canales para los detalles de implementación en Canales, Solución de Pruebas Beta para el flujo de trabajo del producto en Solución de Pruebas Beta, Solución de Versionamiento para el flujo de trabajo del producto en Solución de Versionamiento, y Capgo Prácticas de Entorno: Estadío con Un ID de Aplicación Móvil para el contexto práctico en Capgo Prácticas de Entorno: Estadío con Un ID de Aplicación Móvil.