FAQ

Si tienes dudas que no se resuelven aquí, ¡pregúntanos! Tanto abrir un issue como preguntar en Discord funcionan.

¿Qué es “code push”?

Code push, también conocido como “over-the-air updates” (OTA), es un servicio en la nube que permite a los desarrolladores de Capacitor desplegar actualizaciones en sus apps en producción. Capgo funciona actualmente en Android, iOS y Electron.

“Code Push” es una referencia al nombre de una funcionalidad de despliegue usada por la comunidad de React Native de Microsoft y Expo, ninguno de los cuales soporta Capacitor.

¿Deben coincidir las versiones Capgo CLI mayores con mi plugin o Capacitor?

No. Usa siempre la versión más reciente de Capgo CLI (npx @capgo/cli@latest). Las consolas CLI y Capgo siguen su propio versionado y son compatibles con cualquier versión mayor de los plugins de updater soportados. Los plugins Capgo siguen Capacitor versiones mayores; consulta el versionado de Capgo para etiquetas LTS como @lts-v7.

¿Cuál es la diferencia entre un bundle y un release?

Usamos el término “release” para referirnos a la preparación de un binario para las app stores. Para generar un bundle después, Capgo necesita conocer el binario exacto que se envió a las app stores.

Usamos el término “bundle” para referirnos a un parche que se puede aplicar a un release para actualizarlo a nuevas versiones de code. El npx @capgo/cli@latest bundle upload El comando se usa para generar un bundle a partir de tu nuevo code local, que luego se envía a tus usuarios.

¿Existen limitaciones en las rutas de archivos de Delta update?

Sí:

• Archivos de cero bytes: Los logs de CLI Ignoring empty file... y excluye los archivos vacíos de los archivos delta. No hace fallar la carga, por lo que un archivo vacío puede cambiar el bundle resultante sin detener tu despliegue. No incluyas archivos de cero bytes en las rutas de los bundles Delta.
• Rutas con espacios: Las cargas Delta fallan pronto con un error claro si la ruta del bundle contiene un espacio. Renombra los archivos o directorios para eliminar los espacios antes de cargar una actualización Delta.

Ver Actualizaciones delta para los detalles de configuración.

¿Cuál es el roadmap?

Nuestras tableros de proyecto también son públicos y se encuentran en: https://github.com/orgs/Cap-go/projects

Nuestro equipo también trabaja en público, por lo que puedes ver en qué estamos trabajando en cualquier momento. Nos encantaría responder a cualquier pregunta que tengas sobre nuestra hoja de ruta o prioridades a través de issues de Github o Discord.

¿Puedo usar Capgo con mi equipo?

¡Sí! Todos los planes admiten un número ilimitado de desarrolladores. Solo limitamos las métricas de la app (MAU, almacenamiento y ancho de banda) por organización.

Ver Equipos para más información.

¿Capgo almacena mi code fuente?

No. Los servidores de Capgo nunca ven tu code de origen. Cuando ejecutas npx @capgo/cli@latest bundle upload, Capgo almacena un archivo zip del code minificado/compilado: el mismo code que recibiría un navegador, no tu code de origen.

Para mayor seguridad, tienes dos opciones:

• Cifrado de extremo a extremo: Cifra tu bundle antes de subirlo para protegerlo en almacenamiento y tránsito, y evitar que terceros generen actualizaciones cifradas válidas sin tu clave privada. Esto no impide que los activos web distribuidos sean ingenierizados inversamente, ya que la clave pública está presente en la app distribuida.
• Subida desde URL externa: Almacena el bundle en tu propio servidor y solo proporciona a Capgo el enlace de descarga con la opción --external <url>

Consulta también nuestra política de privacidad: https://capgo.app/privacy

¿Los archivos del bundle son datos privados?

No. Los archivos del bundle son assets web públicos destinados a ser descargados por los usuarios de tu app. Cualquier persona que conozca la URL del bundle puede obtener esos archivos, y Capgo informa a los usuarios de esto durante la configuración y en la documentación.

El acceso a los archivos del bundle no se considera una brecha de datos. No incluyas secretos, credenciales, datos personales ni datos regulados en el bundle de tu app. Si necesitas mayor confidencialidad para casos de alta seguridad, usa cifrado de extremo a extremo, pero sigue tratando los code y assets de la app que distribuyes como públicos desde la perspectiva de reporte de seguridad.

¿Puedo usar Capgo desde mi sistema de CI?

Sí. Capgo está diseñado para usarse desde sistemas de CI. Hemos publicado una guía para Android y Github Actions y iOS, y para GitLab. Otros sistemas de CI deberían ser similares.

No dudes en contactarnos a través de issues de GitHub o Discord si encuentras algún problema.

¿Cómo se relaciona esto con Firebase Remote Config o Launch Darkly?

Code push permite agregar nuevos code / reemplazar code en el dispositivo. Firebase Remote Config y Launch Darkly son ambos sistemas de configuración. Te permiten cambiar la configuración de tu app sin tener que lanzar una nueva versión. No están diseñados para reemplazar code.

¿Cuánto añade esto al tamaño de las dependencias?

No lo he medido recientemente, pero espero que la librería push de code añada menos de un megabyte a las apps de Capacitor. Sabemos cómo reducirlo aún más cuando sea prioridad. Si el tamaño es un bloqueante para ti, ¡avísanos!

¿Funciona Capgo en el simulador de iOS 18.4?

No. Debido a un problema upstream que afecta al simulador de iOS 18.4, Capgo no se ejecuta de forma fiable allí. Prueba en un dispositivo real o usa otra versión del simulador de iOS.

Consulta los detalles en el issue de React Native: facebook/react-native#50510

¿El push de code funciona con apps grandes?

Sí. No hay límite en el tamaño de la aplicación que se puede actualizar con code push. Como se indica below, Capgo puede cambiar cualquier code JS de tu aplicación, sin importar el tamaño.

Ten en cuenta: un tamaño mayor dificulta que los usuarios descarguen las actualizaciones. Recomendamos mantener tu app lo más pequeña posible.

¿Para qué puedo usar el push de Capgo code?

Hemos visto una variedad de usos, incluyendo:

• Correcciones de emergencia en apps de producción.
• Enviar correcciones de errores a usuarios de versiones anteriores de tu app.
• Publicar constantemente (p. ej., cada hora).

Ten en cuenta que la mayoría de las tiendas de aplicaciones prohíben publicar code que cambie el comportamiento de la app de manera significativa. Consulta abajo para más información.

¿Qué cuenta como un “MAU” para Capgo?

Un MAU es un Dispositivo Activo Mensual. Un dispositivo único que contacta con Capgo durante un período móvil de 30 días cuenta como un MAU para ese ID de app nativa. El mismo dispositivo físico usado con dos IDs de app nativa distintos cuenta una vez para cada ID; no se deduplica entre ellos.

Si tus sabores difieren solo en su capa web o en la enrutación de actualizaciones, usa un solo ID de app nativa con canales. Eso mantiene los sabores bajo una sola app de Capgo y simplifica las publicaciones. Usa IDs de app nativa separados cuando un sabor necesite un bundle ID, identidad de firma, conjunto de permisos o listado en la tienda distintos.

En iOS, v7.25.0+ mantiene el ID de dispositivo aleatorio y específico de la app durante las reinstalaciones normales mediante Keychain. En Android, usa v7.50.1+ (o v5.50.1+ y v6.50.1+ en esas líneas de lanzamiento); el ID se restaura solo si Android Backup/Restore conserva las preferencias de la app. Deshabilitar la copia de seguridad, excluir esas preferencias o borrar los datos de la app genera un nuevo ID de dispositivo. Actualizar la app no crea un nuevo ID de dispositivo.

Para builds de prueba y desarrollo, desactiva la entrega a builds de desarrollo y emuladores en canales de producción. Eso controla la entrega, no el MAU: un dispositivo aún puede contar cuando contacta con Capgo. Para mantenerlo fuera del uso de producción, deshabilita las actualizaciones en vivo y no llames a los endpoints de producción de Capgo. Consulta Prueba Native Builds sin Live Updates para la configuración exacta.

¿Para qué no podemos usar el Capgo code push?

Capgo no puede modificar el code nativo, como Java, Kotlin, Objective-C, Swift, plugins nativos o configuración nativa. Esos cambios requieren una nueva versión nativa de la app. Para el alcance de la revisión de tiendas, ver políticas de App Store y Google Play.

¿Puedo actualizar cambios en capacitor.config.ts vía Capgo?

No. Regla breve: Capgo puede enviar la carpeta de build web generada, incluyendo HTML, CSS, JavaScript, assets y cambios de paquetes de JavaScript puro empaquetados en esa salida. Los cambios en capacitor.config.ts, configuración de plugins nativos, instalación o actualización de paquetes nativos y todo lo que deba actualizar el proyecto de iOS o Android a través npx cap sync o npx cap copy requieren una versión nativa de la app.

El archivo de configuración Capacitor se lee en el momento del build nativo y se compila en el binario de la app nativa. Si necesitas cambiar tu configuración de Capacitor, debes:

1. Actualizar capacitor.config.ts localmente
2. Recompila tu app nativa (npx cap sync seguido de un build nativo)
3. Envía el nuevo binario a las tiendas de apps

¿Capgo envía la app a las tiendas por mí?

Capgo Build puede compilar y firmar un proyecto nativo de iOS o Android ya preparado y, si está configurado, enviar el resultado firmado a App Store Connect o Google Play. Puedes mantener tu CI actual para dependencias privadas, builds web, sincronización de Capacitor y preparación nativa personalizada; Capgo recibe el proyecto nativo preparado para el paso de build nativo.

Ver Build de Capgo y la referencia de configuración de build para las opciones de workflow y envío a tiendas.

¿Qué almacena Capgo en el disco y dónde?

El actualizador de Capgo (incluido en tu aplicación al compilarla) almacena en caché el último bundle descargado en el único directorio que capacitor permite para cargar code. En Android, se encuentra en /data/user/0/com.example.app/code_cache/capgo_updater aunque la base de esa ruta la proporciona el sistema de Android y puede cambiar dinámicamente en tiempo de ejecución. En dispositivos iOS, los datos se almacenan bajo Library/Application Support/capgo.

The Capgo command line tools (e.g. npx @capgo/cli@latest bundle upload) se instalan en el disco en las cachés de npm, tus accesos se guardan en tu directorio de inicio en ~/.capgo.

¿Cómo se relaciona esto con Capacitor Hot Reload?

La función de recarga rápida de Capacitor es solo para desarrollo. Code push es para producción.

Hot reload es una función de Capacitor que te permite cambiar code en el dispositivo durante el desarrollo. Requiere compilar la app de Capacitor con un proxy para conectarse a tu máquina local.

El push de Code es una función que te permite cambiar code en el dispositivo en producción. Utilizaremos varias técnicas diferentes para hacer esto posible según la plataforma.

¿Qué tipos de cambios admite el Capgo code push?

Capgo puede modificar cualquier code JS de tu aplicación. Esto incluye la code de la app y el code generado. También puedes actualizar dependencias en package.json siempre que no requieran cambios nativos de code.

No tenemos planes de soportar cambios en code nativo (p. ej. Java/Kotlin en Android o Objective-C/Swift en iOS), y la herramienta te advertirá si detecta que has cambiado code nativo, ya que no se incluirá en el bundle.

¿Es compatible con la Web?

El push de Code no es necesario para web, ya que la web ya funciona así. Cuando un usuario abre una app web, descarga la última versión del servidor si es necesario.

Si tienes un caso de uso para push de code con web, ¡nos encantaría saberlo!

¿Funcionará en iOS, Android, Mac, Windows, Linux, etc.?

Sí.

Hasta ahora nos hemos centrado en el soporte para Android, iOS y Electron, y el push de code está listo para producción en los tres.

¿Qué versiones de OS soporta Capgo?

Capgo admite las mismas versiones de Android que Capacitor.

Capacitor admite actualmente Android API nivel 22+ y iOS 13.0+: https://capacitorjs.com/docs/main/reference/support-policy

¿Qué versiones de Capacitor soporta Capgo?

Capgo actualmente solo soporta versiones estables recientes de Capacitor. También podríamos soportar versiones anteriores de Capacitor, solo que aún no hemos creado la infraestructura necesaria para mantenerlas con el tiempo. Tenemos previsto soportar más versiones de Capacitor en el futuro, incluyendo cualquier versión para nuestros clientes enterprise. https://github.com/Cap-go/capgo/issues/1100

Capgo sigue las versiones estables de Capacitor y suele actualizarse en pocas horas tras cualquier release estable. Nuestro sistema para hacer estas actualizaciones es automatizado y tarda unos minutos en ejecutarse. Después hacemos una verificación manual adicional antes de publicar en nuestros servidores.

¿Cómo se relaciona esto con el proceso de revisión o las políticas de la App/Play Store?

Capgo solo entrega cambios a la capa web de Capacitor: el HTML, CSS, JavaScript y los assets que ya se ejecutan en el WebView de la app. No cambia el binario nativo, los plugins nativos, los permisos, los entitlements, la firma ni los metadatos de la tienda.

Usa un release nativo de la tienda para cada cambio nativo y para los cambios sustanciales que puedan afectar el propósito o la funcionalidad revisados de la app. Mantén las live updates dentro de la experiencia de la app que enviaste y comunicaste a los usuarios.

¿Puede Capgo causar un rechazo de Apple por ejecución remota de code?

No. Eso no es posible. Capgo no instala ni ejecuta code nativo, bibliotecas dinámicas, frameworks ni plugins, y no puede llamar a dlopen, dlsym, performSelector:, o method_exchangeImplementations(). Solo reemplaza JavaScript, HTML, CSS y recursos estáticos dentro del WebView o del motor JavaScriptCore ya compilado en el binario revisado.

Cuando la revisión de la app cita la directriz 2.5.2 o «ejecución remota de code», no trates Capgo como la causa. Lee la notificación de revisión y luego inspecciona el proyecto nativo y otros SDKs en busca de carga de ejecutables o uso de API privados. Una nota de revisión pasada sobre enlazado dinámico en la ruta de auto-ocultado de la pantalla de inicio de Capgo era un error en ese plugin nativo, no en las actualizaciones en vivo, y ese enlace fue eliminado.

¿La ejecución remota de code de Apple afecta a Capgo?

No. Capgo no puede provocar un rechazo por ejecución remota de code. Ver ¿Puede Capgo causar un rechazo de Apple por ejecución remota de code?. Capgo está diseñado para la capa web interpretada en apps de Capacitor. No instala ni ejecuta code nativo tras la revisión. Apple sigue evaluando cada app según sus propios hechos, y Capgo no puede garantizar el resultado.

De Apple Directriz de revisión de apps 2.5.2 indica que las apps no deben «descargar, instalar o ejecutar code que introduzca o modifique funciones o funcionalidad de la app». Los equipos de revisión citan esa regla, junto con el Acuerdo de Licencia del Programa de Desarrolladores de Apple sección 3.3.1(B) sobre code ejecutable, cuando rechazan apps que usan recursos remotos para cambiar el comportamiento tras la aprobación. Ejemplos típicos incluyen dlopen, dlsym, performSelector:, o scripts remotos que acceden a APIs privadas.

El mismo acuerdo de licencia permite interpretación code descargarse cuando:

• no cambia el propósito principal de la app,
• no elude la firma, el sandbox ni otras funciones de seguridad del SO, y
• no crea una tienda o escaparate para otras aplicaciones.

Sección 3.3.1(C) restringe por separado la provisión, desbloqueo o habilitación de funciones o funcionalidades adicionales a través de mecanismos de distribución distintos a App Store, Custom App Distribution o TestFlight, a menos que Apple otorgue aprobación previa por escrito o la actividad esté permitida según la sección 3.3.9(A) (Compra In-App API). Cómo se aplica esa cláusula a un bundle OTA interpretado-code dado es una cuestión legal para tu equipo y tu asesoría jurídica.

Capgo reemplaza el JavaScript, HTML, CSS y los activos estáticos que ya se ejecutan dentro del WebView o motor JavaScriptCore de tu app. No distribuye binarios nativos, code de máquina, bibliotecas dinámicas ni plugins. la directriz 4.7 (aclareado en noviembre de 2025) se aplica cuando tu app ofrece mini apps, mini juegos, chatbots, plugins o software similar en HTML5 y JavaScript que no está incrustado en el binario. Si los usuarios pueden navegar o lanzar múltiples experiencias de software distintas desde dentro de tu app, evalúa los requisitos adicionales de la sección 4.7 con tu asesoría. Un único producto que actualiza su propio bundle web revisado a través de canales es una experiencia de usuario diferente, pero solo Apple decide si tus metadatos coinciden con esa descripción.

Distribuye capacidades nativas, permisos, credenciales y cambios materiales de funcionalidad a través de un binario normal de App Store. Usa Capgo para correcciones y mejoras de la capa web que permanezcan dentro de la app que enviaste. Ver Ejecución remota de code de Apple y Capgo para un desglose más detallado del cumplimiento, o el paseo por el blog para la Directriz 2.5.2, ADPLA 3.3.1(B) y la aclaración de la Directriz 4.7 de 2025.

¿Capgo garantiza la aprobación en App Store o Google Play?

No. Apple y Google revisan cada app y cada lanzamiento según sus propios hechos, y Capgo no puede garantizar una aprobación individual ni el resultado de una revisión. Tu equipo sigue siendo responsable del contenido de la app, las divulgaciones, el alcance de las actualizaciones y el cumplimiento de las políticas actuales de las tiendas.

Para planificar la revisión y el lanzamiento, lee las políticas oficiales directamente: Directrices de revisión de Apple App Store y Política de abuso de dispositivos y redes de Google Play.

¿Puedo usar Capgo en mi país?

No hemos intentado restringir el acceso a Capgo desde ningún país.

Sabemos que algunos países tienen restricciones sobre a qué URLs se puede acceder desde dentro del país. Capgo actualmente usa Cloudflare Cloud para el hosting, incluidos R2 Storage y los workers de Cloudflare.

Las siguientes URLs son utilizadas por Capgo:

• https://api.capgo.app — utilizadas por las npx @capgo/cli herramientas de CLI para interactuar con los servidores de Capgo, así como el updater de Capgo en los dispositivos de los usuarios para buscar actualizaciones.
• https://*.r2.cloudflarestorage.com — utilizadas por las npx @capgo/cli herramienta de CLI para subir y descargar el bundle

Si todas esas URLs son accesibles desde tu país, Capgo debería funcionar.

Si tu región requiere bloquear el acceso a alguna de esas URLs, avísanos y podemos trabajar contigo para encontrar una solución. Los servidores proxy son una opción.

¿Puedo self-hostear Capgo?

Sí. Enterprise admite despliegues autoalojados de Capgo con licencia cuando necesitas ejecutar el backend del updater en tu propia infraestructura. Consulta Updater autoalojado para ver el modelo de despliegue y los endpoints.

¿El push de code requiere internet para funcionar?

Sí. Se podría plantear ejecutar un servidor para distribuir las actualizaciones al margen de internet en general, pero se necesita algún tipo de conectividad de red para hacer llegar las actualizaciones a los dispositivos.

¿Cómo afecta la falta de conectividad a Capgo?

El updater de Capgo (incluido en tu aplicación al compilar con Capgo) está diseñado para resistir problemas de conectividad de red.

Con el comportamiento de actualización predeterminado, cuando se inicia la app se avisa al updater de Capgo, que lanza un hilo separado para hacer una petición de red a los servidores de Capgo y pedir una actualización. Usamos un hilo separado a propósito para no bloquear nada más que la app esté haciendo. Si la petición de red falla o se agota el tiempo de espera, el updater simplemente volverá a comprobarlo la próxima vez que se inicie la app.

herramientas de línea de comandos de Capgo (ej. npx @capgo/cli@latest bundle upload) requieren conectividad de red para funcionar. Si usas Capgo para distribuir tu app, asegúrate de que tu sistema de CI tenga conectividad de red.

¿Qué pasa si un usuario no actualiza durante mucho tiempo y se pierde una actualización?

Nuestra implementación siempre envía una actualización adaptada específicamente al dispositivo que la solicita, actualizando siempre al solicitante a la última versión disponible. Por tanto, si un usuario no se actualiza durante un tiempo, “perderá” las actualizaciones intermedias.

El servidor de actualizaciones podría modificarse para permitir responder con la siguiente versión incremental o con la última versión, según las necesidades de tu aplicación. Avísanos si te resultan importantes otros comportamientos de actualización.

¿Cómo se relaciona Capgo con Capacitor?

Capgo es un plugin para Capacitor que añade push de code. Capgo no es un sustituto de Capacitor. Puedes seguir usando las herramientas de Capacitor que ya conoces y te gustan.

Hacemos seguimiento de la última versión estable de Capacitor y actualizamos nuestro plugin push de code para que funcione con ella.

¿Cuándo se realizan las actualizaciones?

Por defecto, el actualizador de Capgo busca actualizaciones al iniciar la app. Se ejecuta en un hilo en segundo plano y no bloquea el hilo de la UI. Las actualizaciones se instalarán mientras el usuario usa la app y se aplicarán la próxima vez que se reinicie la app.

También es posible ejecutar manualmente el actualizador de Capgo usando el @capgo/capacitor-updater package, a través del cual es posible activar actualizaciones en cualquier momento, incluso mediante una notificación push.

El actualizador de Capgo está diseñado para que, cuando no haya red o el servidor esté caído o inaccesible por cualquier otro motivo, la app siga funcionando con normalidad. Si alguna vez decides eliminar una actualización de nuestros servidores, todos tus clientes seguirán funcionando con normalidad.

Hemos añadido la posibilidad de hacer rollback de los parches. Lo más sencillo es asignar un bundle anterior a tu channel para revertirlo.

¿Debo mantener mi app_id en secreto?

No. El app_id se incluye en tu app y es seguro que sea público. Puedes incluirlo en el control de versiones (incluso de forma pública) y no preocuparte de que alguien más acceda a él.

Alguien que tenga tu app_id puede obtener la última versión de tu app desde los servidores de Capgo, pero no puede enviar actualizaciones a tu app ni acceder a ningún otro aspecto de tu cuenta de Capgo.

¿Qué información se envía a los servidores de Capgo?

El inventario completo de datos, el comportamiento de los endpoints y los controles de privacidad están documentados en Cumplimiento.

Configurar statsUrl: '' para desactivar los informes explícitos de estadísticas del actualizador. También puedes enviar statsUrl a un proxy o endpoint que controles; consulta el manejo de estadísticas en infraestructura autoalojada. Update checks still need an app-scoped device identifier so Capgo can select the correct update and measure monthly active devices.

El lista de subprocesadores es nuestra fuente pública de verdad actualizada para proveedores, ubicaciones de procesamiento, mecanismos de transferencia e historial de cambios.

¿Puedo usar Capgo para apps con datos sensibles HIPAA?

Sí, pero tu responsable de cumplimiento debe elegir el modelo de despliegue adecuado. Capgo Cloud no se presenta actualmente como un procesador de estadísticas alojado que cumpla HIPAA. Por defecto, los datos del updater están limitados al dispositivo y no se vinculan a un usuario conocido de la app, y muchos equipos usan ese modelo con éxito.

Para revisiones más estrictas, puedes geolocalizar el tráfico de los plugins, desactivar las estadísticas configurando statsUrl a una cadena vacía, hacer self-hosting solo del endpoint de estadísticas o usar self-hosting con licencia. No llames a CapacitorUpdater.setCustomId(...) con un email, user ID, patient ID, employee ID o cualquier valor que vincule la telemetría del updater con una persona.

Ver Cumplimiento HIPAA para la configuración técnica completa y las compensaciones de observabilidad cuando las estadísticas están desactivadas.

¿Puedo mantener los datos de Capgo live update en Europa?

Sí. Las apps que necesiten residencia de datos en la UE para el tráfico del plugin Capgo Cloud pueden apuntar los endpoints del updater al host de la UE:

• updateUrl: https://plugin.eu.capgo.app/updates
• statsUrl: https://plugin.eu.capgo.app/stats
• channelUrl: https://plugin.eu.capgo.app/channel_self

Usa las tres URLs de la UE juntas para que las comprobaciones de update, las estadísticas y la asignación de canales usen la misma ruta de datos regional. Como estos valores residen en capacitor.config.ts, las apps móviles en producción necesitan un release nativo antes de que las instalaciones existentes usen los nuevos endpoints.

Ver Ubicación de datos para ver ejemplos exactos de Capacitor y Electron.

¿Qué plataformas soporta Capgo?

Actualmente, Capgo soporta Android, iOS y Electron. Todas están listas para producción.

El uso de Capgo para iOS, Android o Electron puede decidirse de forma independiente. Puedes definir tu estrategia de canales para Android y para un ipa compilado para la App Store, o para canales de Electron, según lo necesites.

Capgo puede adaptarse (con relativa facilidad) para soportar desktop o targets embebidos. Si esto es importante para ti, avísanos.

¿Cómo interactúa Capgo con Play Testing Tracks o Apple TestFlight?

Cada tienda de apps tiene sus propios mecanismos para distribuir apps a grupos limitados de usuarios (ej. “internal testing”, “closed beta”, etc.). Todos sirven para segmentar a tus usuarios en grupos y distribuir versiones específicas de tus apps a cada uno.

Lamentablemente, no todos estos mecanismos permiten que terceros detecten cuándo se instalan apps en un Test Track específico o vía TestFlight. Por tanto, no tenemos visibilidad fiable sobre la composición de estos grupos y no podemos restringir el acceso a los parches de Capgo basándonos en ellos. https://stackoverflow.com/questions/53291007/can-an-android-application-identify-the-test-track-within-google-play https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

Si quieres segmentar la disponibilidad del bundle de Capgo, tienes 4 opciones posibles:

1. Usa un channel separado para cada grupo. Es el enfoque más directo, pero requiere gestionar múltiples channels. Es posible que ya tengas dev channels y prod channels con distinta disponibilidad. Así, puedes actualizar tus dev channels, verificarlos y luego actualizar tus prod channels por separado. Recomendamos usar branches / tags en tu control de versiones para ayudar a hacer seguimiento de las fuentes asociadas a cada release.
2. Haz seguimiento de tu propio conjunto de usuarios opt-in, desactiva las actualizaciones automáticas y lanza actualizaciones solo para ciertos usuarios mediante el @capgo/capacitor-updater package. Esto ya funciona, pero requiere que gestiones tu propia lista de opt-in.
3. Capgo permite crear su propio mecanismo de opt-in por dispositivo (similar a Test Tracks o TestFlight, solo que agnóstico de plataforma). Esto permite que tu equipo de QA haga opt-in al bundle antes de que se promocionen al público general.
4. Usa rollouts progresivos para entregar un bundle candidato a un subconjunto aleatorio y persistente de un channel. Configura un rollout del 0 al 100%, o usa --rollout-percentage-bps para incrementos del 0,01 %; configura la duración de la caché de 60 segundos a 365 días y una política opcional de pausa automática. Esto no selecciona un grupo de dispositivos con nombre.

Facturación

¿Cómo puedo subir o bajar de plan?

Puedes subir o bajar de plan en cualquier momento desde tu dashboard: https://console.capgo.app/settings/organization/plans. Los upgrades entran en vigor de inmediato. Los downgrades se aplican al final de tu ciclo de facturación actual.

¿Qué pasa si alcanzo mi límite de MAU?

Capgo te envía un email al 50%, 70%, 90% y 100% de tu límite de MAU. Una vez que alcanzas el límite, las actualizaciones en vivo se bloquean hasta el final de tu ciclo de facturación. Sube a un plan superior o compra créditos para seguir enviando actualizaciones. Consulta Precios de Capgo y Precios para ver los niveles de plan.

¿Ofrecen reembolsos?

Salvo que la ley exija lo contrario, las cuotas de suscripción pagadas no son reembolsables. Algunas solicitudes de reembolso podrán evaluarse caso por caso a discreción exclusiva de Capgo. Contacta con soporte si crees que cumples los requisitos.

¿Cuándo se reinicia mi periodo de facturación?

Los periodos de facturación se reinician automáticamente cada mes, en el mismo día en que te suscribiste por primera vez a Capgo. Por ejemplo, si te suscribiste el día 15, tu periodo de facturación se reiniciará el 15 de cada mes.

¿Cómo cancelo mi suscripción?

Puedes cancelar tu suscripción en cualquier momento desde tu dashboard: https://console.capgo.app/settings/organization/plans

¿Puedo pagar un año por adelantado?

Sí. Puedes elegir la facturación anual en la configuración del plan de tu organización.

¿Qué cuenta para el almacenamiento y podemos cambiar la retención?

El almacenamiento incluye los bundles históricos retenidos y sus assets Delta en tus canales. Controlas la retención de bundles sin usar para cada app en los ajustes de la app. Los bundles vinculados a un canal activo o rollout se mantienen protegidos para que sigan disponibles para entrega y rollback.

¿La replicación regional multiplica el almacenamiento o el ancho de banda?

No. Un bundle se cuenta una sola vez para el almacenamiento, sin importar las regiones que lo sirvan. El ancho de banda tampoco se multiplica por regiones: ver ¿Cómo se calcula el ancho de banda?.

¿Cómo se calcula el ancho de banda?

El ancho de banda solo cuenta los archivos que un dispositivo descarga realmente de Capgo:

• Actualizaciones delta: cuando subes con --delta, un dispositivo solo descarga los archivos que cambiaron desde la versión que ya tiene. Solo esos archivos cuentan. Los archivos sin cambios, como imágenes grandes o fuentes, no se vuelven a descargar y no cuestan nada. Ver Actualizaciones delta.
• Caché de borde: si el archivo o el zip solicitado ya está en el edge cache, esa descarga no consume tu ancho de banda. Esto aplica tanto a archivos Delta como a zips completos.
• Descargas reanudables: si una descarga se interrumpe, el dispositivo se reanuda desde donde se quedó. La parte ya descargada no se vuelve a bajar ni se cuenta de nuevo.
• Zip completo: bundles subidos sin --delta, o dispositivos con una versión de plugin sin soporte para Delta, descargan el zip completo. Solo cuenta cuando no se sirve desde el edge cache.

Para mantener el ancho de banda bajo, sube con --delta y mantén los assets grandes que rara vez cambian en rutas de archivos estables.

¿Qué incluye el SLA de Enterprise?

Enterprise incluye un compromiso de disponibilidad mensual del 99,9 % para la plataforma de producción. Si no se cumple, la escala de créditos de servicio es del 10 % al 30 % según la disponibilidad mensual. Los objetivos iniciales de respuesta de soporte son P1: una hora, 24/7/365; P2: dos horas hábiles; P3: un día hábil; y P4: dos días hábiles. Consulta el SLA de Enterprise para conocer los términos completos.

Estadísticas y analíticas

Las estadísticas de tu dashboard se actualizan cada medianoche UTC. Las estadísticas se calculan a partir de MAUs únicos activos durante el periodo móvil de 30 días.

Cómo se genera el device ID

El device ID se genera en el dispositivo en el primer arranque y se usa para deduplicar las instalaciones por dispositivo y permitirnos cobrar según los usuarios instalados (p. ej., usuarios activos mensuales), en lugar del total de parches o del total de instalaciones de parches.

El MAU es mejor que el número de instalaciones para tarificar Capgo, ya que es más preciso y refleja el coste real de Capgo por dispositivo.

Persistencia del Device-ID:

• iOS: Desde la v7.25.0+, el device ID se guarda en Keychain y persiste tras reinstalaciones normales.
• Android: Usa la v7.50.1+ (o v5.50.1+/v6.50.1+ en esas líneas de release). El device ID solo se restaura cuando Android Backup/Restore mantiene las preferencias de la app.
• Electron: El device ID se guarda en el almacenamiento seguro.
• Advertencia de Android: Desactivar el backup, excluir las preferencias relevantes o borrar los datos de la app genera un nuevo device ID. Android v7.25.0 a v7.50.0 puede generar un nuevo device ID tras una reinstalación incluso con el backup activado.

El device ID está acotado a la app y sirve para la entrega de live updates y la deduplicación de MAU; no es un identificador publicitario ni de seguimiento entre apps.

Los device IDs se listan después de que la app hace check-in con Capgo a través de los endpoints de updater o stats. Un dispositivo no necesita instalar un patch para poder aparecer en la lista de dispositivos.

¿Por qué mi número de dispositivos es distinto de mis MAU?

La lista de dispositivos y los MAU se basan en señales distintas.

La lista de dispositivos muestra los últimos metadatos conocidos de cada dispositivo, como el device ID, la plataforma, la versión del plugin, la versión del OS, la versión nativa, el channel, el bundle instalado y el país de la solicitud cuando esté disponible. El país de la solicitud es el último code válido de dos letras recibido en una solicitud gestionada por Cloudflare para ese dispositivo, no la ubicación GPS ni la proporcionada por la app. Las solicitudes sin un país válido no borran el último valor válido. Capgo actualiza estos metadatos cuando la app hace check-in, pero los check-ins repetidos que reportan los mismos metadatos pueden no cambiar la fila ni su hora de última actualización.

Los MAU cuentan dispositivos activos únicos durante el periodo de facturación. Esa actividad puede crecer aunque los metadatos del dispositivo no cambien, así que el número de dispositivos y los MAU pueden ser distintos.

¿Cómo tener actualizaciones distintas por plataforma?

Puedes crear un canal para cada plataforma y desactivar las actualizaciones específicas de plataforma en cada canal.

En el canal de iOS desactiva las actualizaciones de Android y en el canal de Android desactiva las de iOS.

Luego, sube un bundle a cada canal para tener una actualización diferente para cada plataforma.

Si necesitas la misma actualización para ambas plataformas, puedes vincular un bundle a varios canales. No hace falta duplicar el bundle.

Continuar desde las FAQ

Si estás usando FAQ para planificar la entrega de live update, conéctalo con Live Updates de Capgo para el flujo de trabajo del producto en Capgo Live Updates, Resumen para el detalle de implementación en Overview, Funcionalidades para el detalle de implementación en Features, Comportamiento de actualización para el detalle de implementación en Update Behavior, y Tipos de actualización para el detalle de implementación en Update Types.