CLIMA
Windy.com - Pronóstico del tiempo
App de clima donde mapas, alertas y navegación requieren actualizaciones de producción precisas.
- Instalaciones en Google Play
- 32.9M
- Calificación en la tienda
- 4.7
Actualizaciones de producción
Lleva la última corrección a todos tus usuarios
Sube un nuevo web bundle desde CLI o tu CI. Los dispositivos lo descargan en segundo plano y lo ejecutan la próxima vez que la app pase a primer plano. Haz un rollout por porcentaje, monitorízalo en Observe y haz un rollback si algo falla.
Prueba gratuita ilimitada de 14 días. Sin tarjeta de crédito Garantía de devolución de 14 días. Cancela cuando quieras.
¿Necesitas una solución Enterprise? Habla con nuestro equipo
No requiere tarjeta de crédito
Rollback automático integrado
Solo actualizaciones de la capa web
El problema
Lanzar en la store es muy lento para un pequeño fix
El flujo de fixes solo vía store
1
Encuentra el bug
Monitoring o soporte reportan una pantalla rota. El fix son solo unas líneas de JavaScript o CSS.
2
Genera un nuevo binario
Subes la versión, haces build para iOS y Android, y preparas dos envíos a las stores.
3
Espera la revisión
La revisión de la store suele tardar 24–48 horas, a veces mucho más. Un rechazo reinicia la espera.
4
Espera a que los usuarios actualicen
Tras la aprobación, cada usuario aún debe instalar la nueva versión. Hasta entonces, ejecutan el viejo code.
Cada paso añade tiempo entre que el fix está listo y que llega a los dispositivos de tus usuarios.
Why store fixes reach users slowly
24–48h+
Tiempo típico de revisión en tiendas
Apple y Google revisan cada nuevo binario. La revisión suele tardar entre 24 y 48 horas, a veces mucho más, y un rechazo implica volver a enviar.
Por usuario
Las actualizaciones dependen de cada dispositivo
Una actualización de la tienda llega al dispositivo solo cuando el usuario, o su configuración de auto-actualización, la instala. Algunos dispositivos mantienen builds antiguos por mucho tiempo.
2 tiendas
Dos envíos por cada fix
El mismo fix web debe pasar por la App Store y Google Play por separado, cada una con su propia revisión y lanzamiento.
La solución
Cómo un live update llega a tus usuarios
Este es el comportamiento de actualización por defecto de Capgo. Sin prompts de actualización, sin reinicios forzados y sin envíos a la tienda para cambios en la capa web.
Flujo de actualización por defecto
-
La app busca actualizaciones
Cuando la app pasa a primer plano, y cada 10 minutos mientras permanece abierta, el updater solicita a Capgo el último bundle del canal.
Al pasar a primer plano
-
Descarga en segundo plano
El nuevo bundle se descarga mientras el usuario usa la versión actual. Con delta updates, solo se descargan los archivos modificados.
Sin interrupciones
-
Se aplica al reanudar
Cuando el usuario sale de la app, el updater instala el bundle. La próxima vez que la abra, ejecutará la nueva versión.
Próximo primer plano
¿Necesitas que los usuarios vean la nueva versión nada más abrir la app? Los modos de direct update la aplican al inicio mientras se muestra la splash screen.
Ver direct updatesCómo funciona
Cómo los equipos de producción lanzan un fix con Capgo
Un release típico para una app Capacitor que ya está en las stores. Cada comando proviene de la documentación de Capgo CLI.
-
Configura el updater una sola vez
Ejecuta el setup wizard y asegúrate de que tu app llame a notifyAppReady() al iniciar. Un bundle que no haga esa llamada hará rollback automáticamente.
Docs de notifyAppReady()npx @capgo/cli@latest init # in your app start-up code await CapacitorUpdater.notifyAppReady() -
Sube el fix a un slice de producción
Usa --delta para que los dispositivos descarguen solo archivos cambiados, y --rollout para empezar con un grupo pequeño. El resto seguirá en el bundle estable.
Docs de rollouts progresivosnpx @capgo/cli@latest bundle upload --channel production --delta --rollout 5 -
Deja que Capgo detenga un rollout fallido
Activa el auto-pause con un umbral de tasa de error (500 puntos básicos es el 5%). Si los fallos lo superan, Capgo hará rollback del rollout. Monitoriza la nueva versión en Observe mientras se ejecuta.
Docs de Observenpx @capgo/cli@latest channel set production \ --auto-pause-enabled \ --auto-pause-failure-rate-bps 500 \ --auto-pause-action rollback -
Promociona a todos
Cuando los números sean correctos, promociona el bundle a todos los dispositivos del canal. Si no, devuelve el rollout cohort a stable.
Docs de rollbacksnpx @capgo/cli@latest channel set production --rollout-promote # or, if something looks wrong npx @capgo/cli@latest channel set production --rollout-rollback
Diseñado para lanzamientos en producción
El control que los equipos de producción necesitan para lanzar updates sin sorprender a los usuarios.
Actualizaciones delta
Sube con --delta y los dispositivos descargarán solo los archivos que cambiaron desde su bundle actual. Los assets grandes que rara vez cambian se descargan una sola vez.
- Descargas más ligeras para usuarios con redes lentas o limitadas
- En el modo por defecto, las actualizaciones se aplican entre sesiones, no en medio de una
--delta
Solo se descargan los archivos modificados
Rollout progresivo con auto-pausa
Envía un nuevo bundle a un porcentaje fijo y aleatorio de un canal mientras el resto permanece en el bundle estable. Aumenta el porcentaje, promociónlo o haz un rollback desde el CLI o la consola.
- El auto-pause puede pausar o revertir un rollout si la tasa de fallos supera tu umbral
- Observe compara la nueva versión con la anterior antes de aumentar la exposición
1–5%
Un primer paso típico de rollout
Rollback automático
Cada actualización debe demostrar que arranca. Si un nuevo bundle no llama a notifyAppReady() a tiempo, el dispositivo vuelve al último bundle funcional y marca el nuevo como fallido.
- El rollback se activa si no se llama a notifyAppReady() dentro de appReadyTimeout (10 segundos por defecto)
- Revierte un canal completo a cualquier bundle anterior de su historial
10s
appReadyTimeout por defecto antes del rollback automático
Entrega compatible con la revisión de tiendas
Capgo entrega la capa web de Capacitor: JavaScript, CSS y assets. No modifica el binario nativo, plugins, permisos, entitlements ni los metadatos de la app store. La revisión de la tienda es específica para cada app, por lo que sigues siendo responsable del cumplimiento de las políticas y su aprobación.
- Usa un release nativo cuando cambien las capacidades nativas, plugins, permisos o metadatos de la app store
- Mantén claras las notas para el revisor sobre la funcionalidad de la app y la ruta de actualización de la capa web
- Revisa las políticas actuales de Apple y Google antes de cada envío
Qué hacen los equipos de producción con esto
Gestión diaria de releases con live updates implementados. Cada tarjeta enlaza a la documentación.
Corrección de bugs críticos
Un error en el checkout o en el login se soluciona con un fix en la capa web. Haz el upload y los dispositivos lo recibirán en su próxima comprobación de updates.
Docs de comportamiento de las actualizacionesCambios de texto y contenido
Corrige el wording, actualiza textos de ayuda o reemplaza imágenes y otros assets del bundle sin generar un nuevo binario.
Docs de compatibilidad nativaSalud de los releases en Observe
Compara un nuevo bundle con el anterior: tasa de errores, tiempos de carga y WebView, y markers de despliegue por versión.
Docs de ObserveActualizaciones más rápidas con notificaciones
Tras cambiar el bundle de un channel, envía una notificación de update silenciosa para que los dispositivos comprueben cambios de inmediato.
Enviar notificación de updateProtege Native Builds antiguos
Bloquea updates mayores en un channel para que un bundle que requiera nuevo code nativo nunca llegue a un binario antiguo.
Docs de segmentación de versionesRollback desde el historial del canal
Elige cualquier bundle anterior en la pestaña History del canal para volver a activarlo en todos los dispositivos de ese canal.
Docs de rollbacksInfraestructura para apps en producción
Capgo ofrece Live Updates a apps en producción desde 2021.
- Updates al mes
- 1B+
- Dispositivos alcanzados
- 90M+
- Apps que usan Capgo
- 4.7K+
- Latencia típica de API
- ~50ms
Soluciones por tipo de equipo
Encuentra la solución que mejor se adapte a tu equipo
Apps creadas con Capacitor
Las apps de alto tráfico necesitan cambios de UI fiables en producción
Las apps de clima, salud pública y telecomunicaciones dependen de interfaces, alertas y navegación precisas. Las actualizaciones en producción ayudan a lanzar correcciones de interfaz aprobadas mientras se monitorea la adopción antes de ampliar el despliegue.
CLIMA
MÉDICO
Conecte SUS
App de salud pública donde la información y servicios requieren actualizaciones rápidas y confiables.
- Instalaciones en Google Play
- 27.7M
- Calificación en la tienda
- 4.6
HERRAMIENTAS
Mi Naranja
App de telecomunicaciones donde alertas y secciones de cuenta cambian a menudo.
- Instalaciones en Google Play
- 9.3M
- Calificación en la tienda
- 4.2
Testimonios de clientes
Lo que dicen los equipos que publican con Capgo
Sergiu S
Desarrollador principal, drivolino GmbH
“El plugin Capgo Capacitor Updater transformó por completo cómo lanzamos actualizaciones. Lo que antes tardaba días ahora tarda solo minutos.”
Kapil
Fundador de NuTriQ
“Poder lanzar actualizaciones OTA a producción al instante, sin esperar los ciclos completos de revisión de la App Store, ha sido una ventaja operativa enorme.”
Michael Haberler
nethead emeritors
“Buen trabajo con el plugin de actualizaciones. Me funciona de maravilla y las live updates son un gran acelerador para agilizar las pruebas.”
FAQ
Preguntas de equipos de producción
Cómo llegan las actualizaciones a los dispositivos y qué hacer si algo falla.
¿Cuándo recibe un usuario un live update?
Por defecto, la app busca actualizaciones al pasar a primer plano y cada 10 minutos mientras esté abierta. Descarga el nuevo bundle en segundo plano, lo instala cuando el usuario sale de la app y lo ejecuta la próxima vez que la abra. El ajuste autoUpdate permite cambiar este comportamiento.
Docs de comportamiento de las actualizaciones
¿Pueden los dispositivos recibir un fix urgente más rápido?
Sí. Tras cambiar el bundle de un channel, envía una notificación de actualización desde la consola o añade --send-update-notification al bundle upload. Los dispositivos reciben un silent push y comprueban la actualización de inmediato. Esto requiere Capgo Notifications con credenciales de push para iOS y Android. La entrega es best effort: una app offline o cerrada por la fuerza comprobará al lanzarse de nuevo.
Enviar notificación de actualización
¿Qué pasa si una actualización rompe la app?
Si un nuevo bundle no llama a notifyAppReady() en 10 segundos (el appReadyTimeout por defecto), el dispositivo vuelve al último bundle funcional y marca el nuevo como fallido. Para bugs que no impiden el inicio de la app, revierte el progressive rollout o elige un bundle anterior del historial del channel.
Docs de rollbacks
¿Cómo lanzamos primero a unos pocos usuarios?
Haz un upload con --rollout para enviar el bundle a una parte aleatoria y persistente del canal mientras el resto se mantiene en stable. Aumenta el porcentaje, promociona o haz un rollback desde CLI o la consola. El auto-pause puede detener la exposición si la tasa de fallos supera un umbral.
Docs de rollouts progresivos
¿Qué no puede cambiar un live update?
Live Update reemplaza la capa web: JavaScript, HTML, CSS y assets. Los plugins nativos, las actualizaciones de Capacitor, los cambios en capacitor.config y los archivos de proyecto de iOS o Android requieren un release en la store. Capgo verifica la compatibilidad nativa de los bundles al hacer el upload, y los canales pueden bloquear updates en binaries antiguos.
Docs de compatibilidad nativaLanza tu próximo fix como un live update
Prueba el flujo completo en tu propia app durante el trial: haz upload de un bundle, lánzalo a unos pocos dispositivos y haz un rollback.
soporte humano de Martin
Prueba gratuita ilimitada de 14 días. Sin tarjeta de crédito Garantía de devolución de 14 días. Cancela cuando quieras.
¿Necesitas una solución Enterprise? Habla con nuestro equipo