Solución: el canal por defecto de Capgo no actualiza dispositivos

Cambiar el Cloud Default en Capgo enruta los dispositivos nuevos de inmediato. Las instalaciones existentes pueden quedarse en su canal antiguo hasta que vuelvan a conectarse, lo que explica muchos casos en los que el canal default de Capgo cloud no actualiza los dispositivos.

Sigue estos pasos en orden. Primero confirma la asignación del dispositivo, luego inspecciona el build de la app, el estado de sincronización, las reglas de rollout, los logs y la configuración de rollback.

Tabla de contenidos

• Paso 1: Confirma que el dispositivo está asignado al canal default
• Paso 2: Verifica la App, el Native Runtime y la compatibilidad de la Update
• Paso 3: Verificar que el despliegue llegó realmente al canal por defecto
• Paso 4: Forzar una nueva sincronización e inspeccionar los logs del dispositivo
• Paso 5: Revisar reglas de rollout, version gates y rollback automático
• Paso 6: Usa Analytics en tiempo real para hallar el punto exacto del fallo
• Paso 7: Evita que el Default Channel quede desactualizado
• FAQ
• Conclusión

Paso 1: Confirma que el dispositivo está asignado al canal default

El objetivo es averiguar qué regla decide ahora mismo el canal del dispositivo. Un Cloud Default solo se aplica cuando una asignación más fuerte no se ha aplicado ya al dispositivo.

Abre el dashboard de Capgo e inspecciona el dispositivo afectado. Revisa su canal actual, app ID, versión y la hora del último check-in. Compara esos valores con un dispositivo que sí recibió la actualización esperada. Esa comparación suele dejar ver el problema enseguida.

La selección de canal sigue un orden. Primero va un canal forzado. Después, un override de dispositivo del dashboard o de API. Luego, un canal local definido por la app. Y después, Capgo compruebadefaultChannelen la configuración nativa de la app. El Cloud Default es el fallback.

Ese orden hace que un dispositivo pueda ignorar un Cloud Default cambiado sin que aparezca ningún error en el dashboard. Por ejemplo, un build de prueba puede seguir teniendo un canal local de una prueba anterior. La app sigue usando ese valor local hasta que lo borres.

Usa la Guía de depuración del updater de Capgo cuando el canal resuelto está vacío o no es el esperado. Cubre el caso en que la app no tiene un default usable y el dispositivo no tiene override.

A continuación, revisa tu configuración de Capacitor. Una configuración típica puede incluir un canal como este:

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

El campo es opcional. Si lo omites, el dispositivo puede heredar el Cloud Default. Eso puede funcionar bien en builds de producción porque el enrutamiento de canales se queda en Capgo Cloud. Si lo incluyes, asegúrate de que el valor coincida con el canal al que realmente haces deploy.

Ahora busca sobrescrituras locales en la aplicación code. Una llamada asetChannel()cambia la caché local. No crea una Device Override en el backend. Por lo tanto, el dashboard puede no mostrar ninguna sobrescritura aunque la app siga usando el canal local.

Borra ese valor local cuando el dispositivo deba volver a la enrutación normal. Usa el método del plugin que elimina la asignación de canal del dispositivo, o elimina el code que establece el canal y reinstala la app para una prueba limpia.

Conclusión clave: Un Cloud Default modificado no puede reemplazar una asignación de canal de dispositivo, app o local más fuerte.

Paso 2: Verifica la App, el Native Runtime y la compatibilidad de la Update

El objetivo es demostrar que la app instalada puede aceptar el bundle que subiste. Un canal correcto aún no puede entregar una actualización a un runtime nativo incompatible.

Empieza con el app ID. La app instalada en el dispositivo debe usar la misma identidad de app que el proyecto donde subiste el bundle. Una discrepancia puede parecer un problema de canal porque el dispositivo consulta la app incorrecta de Capgo.

Luego, compara la versión del runtime nativo con las reglas de compatibilidad del bundle. Las actualizaciones en vivo de Capgo pueden modificar JavaScript, CSS y activos web. No pueden añadir un plugin nativo ni cambiar el code del proyecto nativo después de que la app se haya publicado. Los cambios nativos siguen requiriendo un nuevo build para la tienda.

Piensa en el runtime nativo como el marco alrededor del code web. Si el nuevo bundle espera un API nativo que la app instalada no tiene, Capgo no debería aplicarlo. Crea y sube una versión nativa compatible antes de probar ese bundle.

Inspecciona la versión y la plataforma de la app instalada. Prueba un bundle de Android en Android primero. Prueba un bundle de iOS en iOS. También confirma que el bundle apunta a la versión correcta de la app cuando tu canal usa puertas de versión.

Después de cambiardefaultChannel, ejecuta el comando de sincronización desde la raíz del proyecto:

npx cap sync

Este paso copia la configuración actualizada en los proyectos nativos. Editarcapacitor.configsin sincronizar deja la app nativa con su configuración de canal anterior. Un build nuevo desde ese proyecto nativo obsoleto seguirá reproduciendo el mismo resultado.

Para una prueba limpia, crea un build nuevo de la app después de sincronizar. No confíes en un binario antiguo instalado en tu teléfono. Desinstálalo cuando necesites eliminar el estado local de canal en caché, luego instala el nuevo build y verifica el canal de nuevo.

El Capgo update behavior documentation explica cuándo el updater busca un bundle. Usa ese momento para probar. Lanza la app o vuelve a primer plano, y espera a que la comprobación termine antes de concluir que la actualización falló.

Revisa también la puerta de versión nativa del bundle. Un bundle puede estar en el canal correcto pero seguir siendo inaccesible si su versión mínima de app no coincide con la del dispositivo. Lee los detalles de la versión en el dashboard en lugar de asumir que la última subida aplica a todas las instalaciones.

Si la app supera estas comprobaciones, has acotado el fallo. La siguiente pregunta es si la versión llegó al canal previsto en primer lugar.

Paso 3: Verificar que el despliegue llegó realmente al canal por defecto

El objetivo es confirmar que el bundle existe en el canal que resuelve el dispositivo. Subir un bundle a un canal no lo hace disponible en todos los canales.

Abre el canal en Capgo Cloud. Revisa el bundle activo, su versión y su estado de despliegue. Compara el nombre del canal con el valor que devuelve la app. Presta atención a diferencias menores comoproductionfrente aprod. Los nombres de canal deben coincidir exactamente.

Si despliegas mediante CI/CD, inspecciona el output del comando en el mismo job que subió el bundle. Confirma el app ID y el channel enviados a CLI. Un pipeline puede terminar con un upload exitoso apuntando por error a un channel de staging.

Luego, revisa el estado del bundle. Un release en draft o inactivo puede verse en el dashboard pero no estar disponible para los dispositivos. Si el channel tiene un staged rollout, es posible que el dispositivo afectado no cumpla su regla de rollout.

Usa un dispositivo de prueba conocido y asígnale un rol claro. Por ejemplo, fija un dispositivo a un channel de test y deja otro en el Cloud Default. Sube un cambio inofensivo y compara sus registros de check-in. Así eliminarás las conjeturas de la prueba.

El motor live OTA de Capgo está diseñado para cambios en la capa web. Puede mover un bundle de JavaScript, CSS o un asset sin esperar una nueva revisión de la tienda. Esa velocidad depende de que el release esté activo en el channel exacto que consulta el dispositivo.

Si cambiaste el Cloud Default hace poco, ten en cuenta el timing del dispositivo. Las nuevas instalaciones usan la nueva ruta de inmediato. Los dispositivos existentes suelen cambiar cuando realizan su siguiente chequeo de actualización. Cerrar y reabrir la app puede ayudar a disparar ese chequeo, pero no puede sobrescribir un channel fijado.

Ahora verifica el resultado dentro de la app. Llama agetChannel()después de que el updater se inicie. Loguea el channel devuelto junto a la versión de la app y la del bundle. Esto es más útil que revisar solo el dashboard porque muestra lo que cree el dispositivo.

Ten en cuenta que habrá un retraso si la app solo comprueba al iniciar o al pasar a primer plano. No lo pruebes abriendo una pantalla que nunca inicie el actualizador. Coloca la comprobación en una ruta de inicio conocida para una build de prueba corta y elimina los logs adicionales antes del release.

Si el canal devuelto es correcto pero no llega ningún bundle, pasa a las reglas de compatibilidad y rollout. Si el canal devuelto es incorrecto, vuelve al paso 1 y elimina la asignación que prevalece sobre Cloud Default.

Paso 4: Forzar una nueva sincronización e inspeccionar los logs del dispositivo

El objetivo es separar un estado local obsoleto de un problema de entrega del lado del servidor. Una nueva comprobación te da nueva evidencia.

Primero, asegúrate de que el dispositivo tenga acceso a la red. Una sesión de la app exitosa no demuestra que el actualizador pueda alcanzar su endpoint. Filtros corporativos, reglas de VPN, portales cautivos o una sesión expirada pueden bloquear la solicitud de actualización.

A continuación, lleva la app al primer plano. Espera a que la verificación del actualizador termine. Si tu app expone un evento de estado de actualización, registra ese evento con el canal actual. Evita registrar solo “actualización iniciada”. Necesitas saber si la app encontró un bundle, lo descargó, lo verificó, lo instaló o lo rechazó.

Usa los logs de dispositivos de Capgo para encontrar la primera etapa fallida. El primer error suele ser más útil que el mensaje final de “actualización fallida”. Por ejemplo, un canal ausente apunta a un problema de enrutamiento. Un rechazo de compatibilidad apunta al runtime nativo o a la restricción de versión. Un error de descarga apunta al acceso a la red o a la solicitud del bundle.

Una reinstalación es una prueba útil, pero cambia la evidencia. Reinstalar puede borrar el estado local del canal. Hazlo después de capturar el canal actual y los logs, no antes.

Para una comprobación repetible, registra estos valores en una línea de log:

• ID de la app y versión nativa
• Canal resuelto desdegetChannel()
• Última verificación del updater
• Versión del bundle encontrada por el servidor
• Resultado de instalación o rechazo

Ese pequeño registro ayuda cuando el dispositivo pertenece a un tester que no puede reproducir el problema bajo demanda. También le da a tu equipo de CI una señal clara para pruebas de humo automatizadas.

Usa el repositorio oficial de la fuente del Updater de Capgo Capacitor cuando necesites inspeccionar el comportamiento del plugin API. En particular, presta atención a la diferencia entre un cambio de canal local y una asignación de dispositivo en el dashboard.

Consejo pro: Captura el canal resuelto antes de limpiarlo. De lo contrario, podrías corregir el estado y perder la pista que explicaba el fallo.

Paso 5: Revisar reglas de rollout, version gates y rollback automático

El objetivo es verificar si Capgo retuvo o revirtió el bundle intencionalmente. A veces, una actualización ausente es simplemente una regla de seguridad funcionando como está diseñada.

Abre la configuración del canal y revisa todas las reglas asociadas a la release. Busca versiones mínimas de la app, ajustes de despliegue por porcentaje, filtros de dispositivos y condiciones vinculadas a la release. Un dispositivo fuera de la regla permanecerá en su bundle actual, incluso si el canal es correcto.

Comprueba también el formato de la versión. Capgo usa versionado semántico para comparar releases. Una puerta de versión que parece correcta a simple vista puede comportarse de manera diferente si la app o el bundle usa un formato inesperado. Mantén el formato consistente entre los native builds y las releases OTA.

Luego revisa el comportamiento del rollback. Un rollback automático puede devolver un dispositivo a un bundle anterior tras un health check fallido. El dashboard puede mostrar el code activo anterior, mientras que el release que esperas sigue presente pero no disponible.

No borres un bundle sospechoso antes de revisar sus eventos. Eliminarlo borra evidencia útil. Primero registra la versión del bundle, el channel, el estado del rollout y el motivo del rollback. Luego decide si pausar el release o publicar una versión validada.

Usa un channel staged para cambios riesgosos. Envía el bundle primero a un grupo pequeño de prueba. Monitorea la adopción y las señales de error. Cuando el release se comporte como esperas, avanza el rollout. Esto evita que un cambio defectuoso en la capa web llegue a todos los dispositivos activos a la vez.

El rollback solo repara el code que OTA puede cambiar. Si el fallo se debe a un plugin nativo faltante o a un API nativo incompatible, necesitas un nuevo build de tienda. Enviar un bundle de JavaScript antiguo no añadirá la pieza nativa que le falta a la app.

Cuando revises una regla, hazte tres preguntas:

• ¿Cumple este dispositivo con la versión de la app?
• ¿El dispositivo está en el grupo de rollout?
• ¿Un health check o una acción manual lo devolvió a un bundle anterior?

Capgo es útil aquí porque el mismo modelo de channel puede gestionar un release staged, admitir un rollback y mostrar la actividad de updates en un solo flujo. Mantén el conjunto de reglas pequeño. Una política breve es más fácil de auditar que una pila de excepciones creadas durante un incidente.

Si necesitas comprobaciones basadas en API, la Capgo documentación pública de API describe los recursos de dispositivos, canales y bundles. Úsalo para comparar la vista del servidor con lo que reporta la app. Esa comparación puede revelar un filtro del dashboard obsoleto o una asignación de dispositivo creada por automatización.

Un rollback es una red de seguridad, no un sustituto de las pruebas. Mantén un bundle validado disponible en cada canal de producción.

Paso 6: Usa Analytics en tiempo real para hallar el punto exacto del fallo

El objetivo es dejar de tratar “no actualizado” como un solo fallo. Analytics puede mostrar si el dispositivo nunca hizo check-in, no encontró un bundle elegible, falló durante la descarga o hizo rollback después.

Empieza con el grupo de dispositivos afectados. Filtra por versión de la app, plataforma, canal y versión del bundle. Busca un patrón. Si solo falla una build antigua, el problema puede ser un gate de compatibilidad nativa. Si fallan todos los dispositivos de un canal, inspecciona el canal o el deployment.

Compara la adopción a lo largo del tiempo. Una línea plana tras el release sugiere problemas de routing o elegibilidad. Un aumento seguido de una caída sugiere errores de instalación o un rollback. Un aumento lento puede significar simplemente que los dispositivos aún no han abierto la app.

Usa los timestamps con cuidado. La hora del evento en el dashboard puede diferir de la hora local del usuario. Cruza el evento de actualización con el último check-in del dispositivo. Esto ayuda cuando un tester dice que la actualización falló antes de que la app realmente hiciera el check-in.

Analytics también te ayuda a probar un cambio de canal de forma segura. Cambia una variable a la vez. Mantén el bundle constante mientras pruebas el routing. Luego mantén el routing constante mientras pruebas un nuevo bundle. Si cambias ambos, los datos no pueden decirte qué cambio solucionó el problema.

Para un incidente, guarda un pequeño conjunto de evidencias:

• El identificador del dispositivo o la etiqueta de prueba interna
• Canal resuelto
• Versión de la app nativa
• Bundle esperado y bundle instalado
• Hora del último check-in
• Evento de rollback o rechazo

La vista en tiempo real de Capgo es más útil cuando tu proceso de release envía actualizaciones vía CI/CD. Un job de deployment puede subir un bundle, mientras un paso de monitoreo verifica que los dispositivos de prueba reporten el canal y el bundle previstos. Eso convierte una queja manual en un release gate.

Mantén los datos de analytics vinculados a los registros de release. Escribe el commit o la referencia de build en tus notas de deployment. Cuando dos bundles tengan etiquetas de versión similares, la referencia de build te dirá qué code se movió realmente.

Si solo los dispositivos existentes fallan tras un cambio en el Cloud Default, espera a su próximo check-in antes de cambiar más ajustes. Una instalación nueva es un control útil; te indica si la ruta por defecto funciona para dispositivos que no tienen un estado local previo.

Paso 7: Evita que el Default Channel quede desactualizado

El objetivo es hacer visible la deriva del canal antes de que afecte a los usuarios. Una pequeña lista de verificación de releases puede prevenir la mayoría de los casos recurrentes.

Elige un modelo de enrutamiento para cada entorno de la app. Para producción, puedes omitirdefaultChannely dejar que Capgo Cloud controle el valor por defecto. Para un build de prueba, puedes establecer un canal explícito. La configuración peligrosa es una mezcla de sobrescrituras locales antiguas, configuración nativa obsoleta y un nuevo Cloud Default que nadie verifica.

Ponnpx cap syncen la ruta de build después de los cambios de configuración. Haz que el build falle si el paso de sincronización falla. El comando es simple, pero omitirlo puede incrustar el canal de ayer en el binario nativo de hoy.

Añade una prueba de humo tras el despliegue. El dispositivo de prueba debe lanzar la app y llamargetChannel(), verifica el bundle esperado y registra el resultado. La verificación suele ser el paso que falta en los flujos OTA. Una sola carga no demuestra casi nada.

Mantén el canal local code detrás de un feature flag claro. Si un helper de pruebas llamasetChannel(), asegúrate de que las builds de producción no lo incluyan por accidente. Recuerda que la caché local puede no aparecer como una sobrescritura en el dashboard, por lo que la interfaz no puede detectar todos los problemas.

Usa una lista de verificación de release como esta:

1. Confirma el ID de la app y la versión nativa.
2. Elige el canal de destino.
3. Sube el bundle a ese canal.
4. Confirma que el bundle está activo.
5. Ejecuta la prueba de humo en el dispositivo.
6. Revisa el canal devuelto congetChannel().
7. Observa la adopción antes de ampliar el despliegue.

Mantén la protección de rollback activada para las releases de producción. Un patrón de fallo común es desplegar sin un canal claro ni un plan de rollback. Eso deja al equipo con menos formas seguras de detener un bundle defectuoso.

Capgo utiliza una suscripción por organización, con una prueba gratuita de 14 días. Aprovecha la prueba para validar tu flujo de release en builds reales de la app, no solo para revisar el dashboard. Prueba un despliegue por etapas, una prueba de rollback y una verificación automatizada del canal.

La seguridad debe estar en la misma checklist. Protege los tokens de CI/CD. Limita quién puede cambiar el Cloud Default. Mantén las credenciales de despliegue de producción fuera de los scripts locales. Un cambio no autorizado de canal puede parecer un dispositivo obsoleto hasta que revises la auditoría.

Para equipos que publican con frecuencia, mantén el proceso aburrido. Un comando para desplegar. Un dispositivo de prueba conocido. Una regla de canal clara. Rastrea, adopta, revierte.

Conclusión clave: Evita el enrutamiento obsoleto sincronizando la config, evitando overrides locales ocultos, probando el canal resuelto y manteniendo el rollback listo.

FAQ

¿Por qué el canal predeterminado en la nube de Capgo no actualiza los dispositivos existentes?

Los dispositivos existentes pueden mantener su canal antiguo hasta su próxima verificación de actualización. Un canal local, un override del dashboard o una asignación forzada también pueden tener prioridad sobre el Cloud Default. Confirma el canal resuelto del dispositivo congetChannel(), elimina cualquier asignación más fuerte y lleva la app al primer plano.

¿Cambiar el Cloud Default de Capgo modifica todas las apps instaladas?

No, cambiar el Cloud Default no reescribe al instante el canal de todas las apps instaladas. Los nuevos dispositivos pueden usar el nuevo default de inmediato. Las instalaciones existentes deben hacer check-in antes de poder cambiar, y aún así no cambiarán si se aplica una regla de canal más fuerte o una override local.

¿Qué hace npx cap sync para un cambio de canal de Capgo?

npx cap synccopia la configuración actualizada de Capacitor en los proyectos nativos. Si cambiasdefaultChannelpero omites el sync, el próximo native build puede seguir conteniendo la configuración de canal antigua. Ejecuta el comando desde la raíz del proyecto, luego construye e instala un binario de prueba nuevo.

¿setChannel crea un override de dispositivo en Capgo?

No,setChannel()cambia el canal almacenado localmente por la app. No crea un Device Override en el backend, por lo que el dashboard de Capgo puede no mostrar el dispositivo como override. Limpia la asignación local cuando el dispositivo debería volver a la ruta por defecto, luego verifica el resultado congetChannel().

¿Puede Capgo actualizar el code nativo mediante un bundle OTA?

No, las actualizaciones OTA de Capgo se aplican a la capa web de code como JavaScript, CSS y assets. Un plugin nativo, permiso o cambio de API nativo requiere un nuevo build de la store. Si el bundle espera code nativos que la app instalada no tiene, la actualización puede ser rechazada incluso si el canal es correcto.

Conclusión

Empieza con el canal resuelto, no con el default del dashboard. Revisa las asignaciones, ejecutanpx cap sync, verifica el bundle contra el runtime nativo e inspecciona los logs del dispositivo antes de cambiar las reglas de rollout. Luego añade una pequeña prueba post-deploy en Capgo que llame agetChannel()y confirma el bundle esperado.