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 desde 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 que el upload falle, por lo que un archivo vacío puede cambiar el bundle resultante sin detener tu deployment. No incluyas archivos de cero bytes en las rutas del Delta bundle.
• Rutas con espacios: Los uploads de Delta fallan rápidamente con un error claro cuando una ruta del bundle contiene un espacio. Renombra archivos o directorios para eliminar los espacios antes de subir un Delta update.

Ver Actualizaciones delta para detalles de configuración.

¿Cuál es el roadmap?

Nuestros tableros de proyecto también son públicos y están en: https://github.com/orgs/Cap-go/projects

Nuestro equipo también trabaja de forma pública, así que puedes ver en qué estamos trabajando en cualquier momento. Estaremos encantados de responder cualquier duda sobre nuestro roadmap o prioridades mediante issues en Github o Discord.

¿Puedo usar Capgo con mi equipo?

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

Ver Teams para más información.

¿Capgo almacena mi code fuente?

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

Para mayor seguridad, tienes dos opciones:

• Cifrado de extremo a extremo: Encripta tu bundle antes de subirlo para protegerlo en almacenamiento y tránsito, y evitar que terceros generen actualizaciones encriptadas válidas sin tu clave privada. Esto no impide la ingeniería inversa de los assets web, ya que la clave pública está 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 o datos regulados en tu app bundle. Si necesitas mayor confidencialidad para casos de uso de alta seguridad, utiliza cifrado de extremo a extremo, pero sigue tratando los code y assets de la app como públicos desde una 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 acciones de Github y iOS, y para GitLab. Otros sistemas de CI deberían ser similares.

No dudes en contactarnos a través de GitHub o Discord si tienes cualquier problema.

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

El push de Code permite añadir nuevos code / reemplazar code en el dispositivo. Firebase Remote Config y Launch Darkly son sistemas de configuración. Permiten cambiar la configuración de tu app sin lanzar una nueva versión. No están pensados 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 un push de code. Como se indica abajo, Capgo puede cambiar cualquier code de JS en tu aplicación sin importar su tamaño.

Nota: Un tamaño mayor dificulta la descarga de actualizaciones para los usuarios. Recomendamos mantener tu app lo más pequeña posible.

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

Hemos visto diversos usos, incluyendo:

• Fixes de emergencia en apps de producción.
• Enviar bug fixes a usuarios con versiones antiguas de tu app.
• Realizar despliegues constantes (ej. cada hora).

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

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

Un MAU es un Monthly Active Device. Un dispositivo distinto que contacte con Capgo durante un periodo móvil de 30 días cuenta como un MAU para ese native app ID. El mismo dispositivo físico usado con dos native app IDs distintos cuenta una vez por cada ID; no se deduplican entre ellos.

Si tus flavours solo difieren en su capa web o en el enrutamiento de updates, usa un único native app ID con canales. Eso mantiene los flavours bajo una sola app de Capgo y simplifica los releases. Usa native app IDs separados cuando un flavour necesite un bundle ID, signing identity, conjunto de entitlements o ficha de tienda distintos.

En iOS, v7.25.0+ mantiene el device ID aleatorio y por app tras reinstalaciones normales usando Keychain. En Android, usa v7.50.1+ (o v5.50.1+ y v6.50.1+ en esas líneas de versión); el ID solo se restaura si Android Backup/Restore mantiene las preferencias de la app. Desactivar el backup, excluir esas preferencias o borrar los datos de la app generará un nuevo device ID. Actualizar la app no crea un nuevo device ID.

Para builds de prueba y desarrollo, desactiva el envío de development-build y emuladores en canales de producción. Eso controla la entrega, no el MAU: un dispositivo puede seguir contando cuando contacta con Capgo. Para evitar su uso en producción, desactiva los live updates y no llames a los endpoints de producción de Capgo. Consulta Prueba Native Builds sin Live Updates para ver la configuración exacta.

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

Capgo no puede cambiar el código nativo de code, como Java, Kotlin, Objective-C, Swift, plugins nativos o la configuración nativa. Esos cambios requieren un nuevo release de la app nativa. Para el alcance de la revisión de tiendas, consulta las políticas de App Store y Google Play.

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

No. Regla rápida: Capgo puede enviar la carpeta del build web generado, incluyendo HTML, CSS, JavaScript, assets y cambios de paquetes en JavaScript puro incluidos en ese output. Los cambios en capacitor.config.ts, configuración de plugins nativos, instalaciones o actualizaciones de paquetes nativos y cualquier cambio que deba actualizar el proyecto de iOS o Android mediante npx cap sync o npx cap copy requieren un release de la app nativa.

El archivo de configuración de Capacitor se lee en el tiempo de Native Build 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 updater de Capgo (incluido en tu app al compilarla) cachea el último bundle descargado en el único directorio que capacitor permite para cargar code. En Android, se ubica en /data/user/0/com.example.app/code_cache/capgo_updater aunque la base de esa ruta la proporciona el sistema Android y puede cambiar dinámicamente en runtime. En dispositivos iOS, los datos se guardan en Library/Application Support/capgo.

Las herramientas de línea de comandos de Capgo (ej. npx @capgo/cli@latest bundle upload) se instalan en los caches de npm en el disco; tus logins se guardan en tu home en ~/.capgo.

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

El Hot reload de Capacitor es solo para desarrollo. El push de Code es para producción.

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

El push de Code es una función que permite cambiar code en el dispositivo en producción. Usaremos diversas técnicas para lograrlo según la plataforma.

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

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

No tenemos planes de permitir cambios en el código nativo de code (ej. Java/Kotlin en Android u Objective-C/Swift en iOS); la herramienta te avisará si detecta cambios en code, ya que no se incluirán en el bundle.

¿Es compatible con Web?

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

Si tienes un caso de uso para code push 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 SO soporta Capgo?

Capgo soporta las mismas versiones de Android que Capacitor.

Capacitor soporta actualmente Android API nivel 22+ e 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. Podríamos soportar versiones antiguas de Capacitor, pero aún no hemos desarrollado la infraestructura necesaria para mantenerlas. Planeamos 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 rastrea las versiones estables de Capacitor y suele actualizarse pocas horas después de cualquier release estable. Nuestro sistema de actualización es automatizado y tarda unos minutos en ejecutarse. Luego realizamos una verificación manual extra antes de publicar en nuestros servidores.

¿Cómo afecta esto al proceso de revisión o a las políticas de la App/Play Store?

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

Usa un release de la tienda nativa para cada cambio nativo o cambios materiales que afecten el propósito o funcionalidad revisada de la app. Mantén los live updates dentro de la experiencia de app que enviaste y divulgaste 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 nativos, librerías dinámicas, frameworks o plugins, y no puede llamar dlopen, dlsym, performSelector:, o method_exchangeImplementations(). Solo reemplaza JavaScript, HTML, CSS y assets estáticos dentro del WebView o el motor JavaScriptCore ya compilado en el binario revisado.

Cuando App Review cite la Guideline 2.5.2 o “remote code execution”, no consideres a Capgo como la causa. Lee el aviso de revisión e inspecciona el proyecto nativo y otros SDKs en busca de carga de ejecutables o uso de API privado. Una nota de revisión anterior sobre dynamic linking en la ruta de auto-ocultado del splash-screen de Capgo fue un bug de ese plugin nativo, no de los live updates, y ese enlace fue eliminado.

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

No. Capgo no puede causar un rechazo por ejecución remota de code. Consulta ¿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 nativos tras la revisión. Apple sigue revisando cada app según sus propios criterios, y Capgo no puede garantizar un resultado.

De Apple Directriz de revisión de apps 2.5.2 indica que las apps no pueden “descargar, instalar o ejecutar code, lo cual introduce o cambia las funciones o la funcionalidad de la app”. Los equipos de revisión citan esa regla junto con el Apple Developer Program License Agreement sección 3.3.1(B) sobre code ejecutable, cuando rechazan apps que usan recursos remotos para cambiar su 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 evade el signing, el sandbox u otras funciones de seguridad del OS, y
• no crea una tienda o storefront para otras aplicaciones.

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

Capgo reemplaza el JavaScript, HTML, CSS y los assets estáticos que ya se ejecutan dentro del WebView o el motor JavaScriptCore de tu app. No incluye binarios nativos, code de máquina, librerías dinámicas o plugins. la directriz 4.7 (aclarado en noviembre de 2025) se aplica cuando tu app ofrece mini apps en HTML5 y JavaScript, minijuegos, chatbots, plug-ins o software similar que no esté embebido en el binario. Si los usuarios pueden navegar o lanzar múltiples experiencias de software distintas desde tu app, evalúa los requisitos adicionales de la sección 4.7 con asesores legales. Un único producto que actualiza su propio web bundle revisado mediante canales es una experiencia de usuario distinta, pero solo Apple decide si tus metadatos coinciden con esa descripción.

Envía capacidades nativas, permisos, entitlements y cambios de funcionalidad principal mediante un binario normal de la App Store. Usa Capgo para correcciones y mejoras en la capa web que se mantengan dentro de la app que enviaste. Consulta la ejecución remota de code de Apple y Capgo para un desglose de cumplimiento más detallado, o el artículo del blog para la Guideline 2.5.2, ADPLA 3.3.1(B) y la aclaración de la Guideline 4.7 de 2025.

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

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

Para la planificación de lanzamientos y revisiones, lee las políticas oficiales directamente: Directrices de revisión de la App Store de Apple 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 estas URLs, avísanos para buscar una solución juntos. El uso de servidores proxy es una opción.

¿Puedo self-hostear Capgo?

Sí. Enterprise permite despliegues con licencia de Capgo en self-host cuando necesitas ejecutar el backend del updater en tu propia infraestructura. Consulta Updater Self-Hosted para ver el modelo de despliegue y los endpoints.

¿El push de code requiere internet para funcionar?

Sí. Podrías usar un servidor para distribuir las actualizaciones fuera de la internet general, pero se requiere algún tipo de conectividad de red para enviar 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 ser resiliente ante problemas de conectividad.

Con el comportamiento de actualización por defecto, al iniciar la app se alerta al updater de Capgo, que lanza un hilo separado para solicitar una actualización a los servidores de Capgo. Usamos un hilo separado a propósito para no bloquear otras tareas de la aplicación. Si la petición falla o da timeout, el updater simplemente lo intentará de nuevo la próxima vez que se inicie la app.

Las 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 conexión a internet.

¿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 diseñada específicamente para el dispositivo que la solicita, actualizando al cliente siempre a la última versión disponible. Por tanto, si un usuario no actualiza en un tiempo, se

El servidor de actualizaciones podría modificarse para responder con la siguiente versión incremental o la última versión, según las necesidades de tu app. Avísanos si necesitas 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 reemplaza a Capacitor. Puedes seguir usando el tooling de Capacitor que ya conoces y te encanta.

Hacemos el seguimiento de la última versión estable de Capacitor y actualizamos nuestro plugin de push code para que sea compatible.

¿Cuándo se realizan las actualizaciones?

Por defecto, el updater de Capgo busca actualizaciones al iniciar la app. Se ejecuta en un hilo de fondo sin bloquear el hilo de la UI. Las actualizaciones se instalarán mientras el usuario usa la app y se aplicarán al reiniciarla.

También es posible ejecutar el updater de Capgo manualmente usando el @capgo/capacitor-updater package, con el cual puedes disparar actualizaciones en cualquier momento, incluso mediante una notificación push.

El actualizador de Capgo está diseñado para que, si no hay red o el servidor está caído o inaccesible, la app siga funcionando con normalidad. Si decides eliminar una actualización de nuestros servidores, todos tus clientes seguirán operando sin problemas.

Hemos añadido la capacidad de hacer rollback de los parches. Lo más sencillo es simplemente adjuntar un bundle anterior a tu channel para revertir los cambios.

¿Debo mantener mi app_id en secreto?

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

Alguien que tenga tu app_id puede descargar 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 updater. También puedes enviar statsUrl a un proxy o endpoint bajo tu control; consulta el manejo de estadísticas en infraestructura self-hostedLas comprobaciones de Update aún requieren un identificador de dispositivo a nivel de app para que Capgo pueda seleccionar la actualización correcta y medir los dispositivos activos mensuales.

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 de 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 con cumplimiento HIPAA. Por defecto, los datos del updater están limitados al dispositivo y no se vinculan a un usuario de la app, modelo que muchos equipos usan 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, aloja únicamente el endpoint de estadísticas o usa el self-hosting con licencia. No llames 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 requieran residencia de datos en la UE para el tráfico del plugin Capgo Cloud pueden configurar 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. Track your own set of opt-in users, disable automatic updates, and trigger updates only for certain users via the @capgo/capacitor-updater package. Esto ya es posible, pero requiere que gestiones tu propia lista de usuarios.
3. Capgo permite crear su propio mecanismo de opt-in por dispositivo (similar a Test Tracks o TestFlight, pero agnóstico a la plataforma). Esto permite que tu equipo de QA acepte el bundle antes de que se lance al público general.
4. Usa rollouts progresivos para entregar un bundle candidato a un subconjunto aleatorio y persistente de un canal. Configura un rollout del 0 al 100%, o usa --rollout-percentage-bps para incrementos del 0.01%; configura la duración de la caché desde 60 segundos hasta 365 días y una política de auto-pausa opcional. Esto no selecciona un grupo de dispositivos con nombre.

Facturación

¿Cómo puedo cambiar de plan (upgrade/downgrade)?

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 tu plan de 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 no utilizados para cada app en App Settings. Los bundles vinculados a un canal activo o rollout permanecen protegidos para asegurar su entrega y rollback.

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

No. Un bundle cuenta como una sola unidad de almacenamiento, independientemente de las regiones que lo sirvan. El ancho de banda tampoco se multiplica por región: ver ¿Cómo se cuenta el ancho de banda?.

¿Cómo se cuenta el ancho de banda?

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

• Actualizaciones delta: cuando haces upload 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 descargan de nuevo y no tienen coste. Ver Actualizaciones delta.
• Caché de borde: si el archivo solicitado o el zip completo ya está en el edge cache, esa descarga no consume tu ancho de banda. Esto aplica tanto para archivos Delta como para 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 la primera vez que se ejecuta. Se usa para evitar duplicados en instalaciones por dispositivo y permitirnos cobrar según los usuarios instalados (ej. usuarios activos mensuales), en lugar de por parches totales o instalaciones de parches.

El MAU es una mejor solución que el número de instalaciones para el precio de 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 secure storage.
• 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 hasta 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 en cada uno.

Desactiva las actualizaciones de Android en el canal de iOS y las de iOS en el canal de Android.

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

Si necesitas la misma actualización para ambas, puedes vincular un bundle a varios canales sin duplicarlo.

Seguir desde 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.