Saltar al contenido

Preguntas Frecuentes

Si tienes preguntas no respondidas aquí, por favor pregunta! Ambos, abrir una incidencia o preguntar en Discord trabajo.

Code push, también conocido como “actualizaciones sobre la red” (OTA) es un servicio en la nube que permite a los desarrolladores Capacitor desplegar actualizaciones a sus aplicaciones en producción. Capgo funciona actualmente en Android, iOS y Electron.

“Code Push” es una referencia al nombre de una característica de despliegue utilizada por la comunidad de React Native desde Microsoft y Expo, ni de ellas soportan Capacitor.

¿Cuál es la diferencia entre un paquete y una versión?

Sección titulada “¿Cuál es la diferencia entre un paquete y una versión?”

Usamos el término “versión” para referirnos a la preparación de un binario para las tiendas de aplicaciones. Para generar posteriormente un paquete Capgo necesita saber el binario exacto que se envió a las tiendas de aplicaciones.

Usamos el término “paquete” para referirnos a una actualización que se puede aplicar a una versión para actualizarla a nuevas code. El npx @capgo/cli@latest bundle upload comando se utiliza para generar un paquete a partir de su nuevo code local, que luego se envía a sus usuarios.

¿Cuál es el plan de acción?

¿Cuál es el plan de acción?

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

Nuestro equipo también opera en el público, por lo que puede ver qué estamos trabajando en cualquier momento. Estamos encantados de responder cualquier pregunta que tenga sobre nuestro plan de acción o prioridades a través de Github issues o Discord.

¿Puedo usar Capgo con mi equipo?

¿Puedo usar Capgo con mi equipo?

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

Ver Equipos para obtener más información.

No. Los servidores de Capgo nunca ven tu código fuente code. 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 código fuente code.

Para una mayor seguridad, tienes dos opciones:

  • Cifrado de Fin a Fin: Cifra tu paquete antes de subirlo para protegerlo en almacenamiento y tránsito y para evitar que terceros generen actualizaciones cifradas válidas sin tu clave privada. Esto no hace que los activos web distribuidos sean imposibles de revertir porque la clave pública está presente en la aplicación distribuida.
  • Carga de URL Externa: Almacena el paquete en tu propio servidor y proporciona solo al Capgo con el enlace de descarga con la opción --external <url>

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

No. Los archivos de paquete son activos web públicos destinados a ser descargados por los usuarios de su aplicación. Cualquiera que conozca la URL del paquete puede descargar esos archivos, y Capgo informa a los usuarios de esto durante la configuración y en la documentación.

El acceso a los archivos de paquete no se considera una violación de datos. No ponga secretos, credenciales, datos personales o datos regulados en el paquete de su aplicación. Si necesita una confidencialidad más fuerte para casos de uso de alta seguridad, utilice la cifrado de extremo a extremo, pero aún trate los code y activos de la aplicación como públicos desde una perspectiva de informes de seguridad.

Sí. Capgo está destinado a ser utilizado desde sistemas de CI. Hemos publicado una guía para Android y Github Actions y iOSy para GitLab. Otros sistemas CI deberían ser similares.

Por favor, no dude en contactarnos a través de GitHub problemas o Discord si encuentra algún problema.

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

Sección titulada “¿Cómo se relaciona esto con Firebase Remote Config o Launch Darkly?”

El Code push permite agregar nuevos code / reemplazar code en el dispositivo. Firebase Remote Config y Launch Darkly son ambos sistemas de configuración. Permiten cambiar la configuración de su aplicación sin tener que enviar una nueva versión. No están destinados a reemplazar code.

No he medido recientemente, pero espero que la biblioteca de push code agregue menos de un megabyte a las aplicaciones Capacitor. Sabemos cómo hacer esto más pequeño cuando se convierta en una prioridad. Si el tamaño es un obstáculo para usted, por favor, háganoslo saber!

No. Debido a un problema upstream que afecta al simulador de iOS 18.4, Capgo no se ejecuta de manera confiable allí. Por favor, prueba en un dispositivo real o utiliza una versión diferente del simulador de iOS.

Ver detalles en el problema de React Native: facebook/react-native#50510

Sí. No hay límite en el tamaño de la aplicación que se puede actualizar con code push. Como se menciona a continuación, Capgo puede cambiar cualquier code JS en tu aplicación, independientemente de su tamaño.

To note: Un tamaño más grande hace que sea más difícil para los usuarios descargar actualizaciones. Recomendamos mantener su aplicación lo más pequeña posible.

Hemos visto una variedad de usos, incluyendo:

  • Reparaciones de emergencia a aplicaciones de producción.
  • Envío de correcciones de errores a usuarios en versiones antiguas de su aplicación.
  • Envío constante (por ejemplo, cada hora).

Tenga en cuenta que la mayoría de las tiendas de aplicaciones prohíben el envío de code que cambia el comportamiento de la aplicación de manera significativa. Consulte a continuación para obtener más información.

¿Qué se considera un “MAU” para Capgo?

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

Un MAU es un “Usuario Activo Mensual”. En el contexto de Capgo, esto se refiere en realidad a un Dispositivo Activo Mensual. Contamos un MAU como cualquier dispositivo que ha contactado con nuestros servidores en los últimos 30 días. No contamos dispositivos que no han contactado con nuestros servidores en los últimos 30 días.

ImportanteA partir de la versión del plugin v5.10.0, v6.25.0 y v7.25.0, el dispositivoID ahora persiste a lo largo de reinstalaciones de la aplicación. Antes de estas versiones, cada reinstalación de la aplicación generaba un nuevo dispositivoID y se contaba como un nuevo MAU.

Con las versiones actuales:

  • El dispositivoID persiste a lo largo de reinstalaciones de la aplicación (almacenado de manera segura en Keychain en iOS y EncryptedSharedPreferences en Android)
  • Actualizando la aplicación no crea un nuevo ID de dispositivo
  • Durante el desarrollo, si está utilizando una versión antigua del plugin (&#x3C; v5.10.0 / v6.25.0 / v7.25.0), cada reinstalación crea aún un nuevo MAU

Nota: Las descargas de TestFlight y los cambios de canal en Android pueden generar nuevas inscripciones de dispositivos dependiendo de su configuración.

Recomendamos después de la primera configuración, deshabilitar dispositivos de desarrollo y emuladores para reducir la cantidad de dispositivos duplicados.

Como arriba, Capgo no debe usarse para violar las políticas de la tienda de aplicaciones. Consulte a continuación para obtener más información.

También Capgo no admite cambiar el code nativo (por ejemplo, Java/Kotlin en Android o Objective-C/Swift en iOS). La herramienta te advertirá durante una actualización intentada si has cambiado el code nativo.

Puedo actualizar capacitor.config.ts cambios mediante Capgo?

¿Puedo actualizar capacitor.config.ts cambios a través de Capgo?

No. Regla corta: Capgo puede enviar el carpeta de compilación web generada, incluyendo HTML, CSS, JavaScript, activos y cambios de paquetes de JavaScript puro empaquetados en ese resultado. Los cambios en capacitor.config.ts, la configuración de plugin nativo, la instalación o actualización de paquetes nativos y cualquier cosa que deba actualizar el proyecto de iOS o Android a través de npx cap sync o npx cap copy requieren una nueva versión de la aplicación nativa.

El archivo de configuración de Capacitor se lee en tiempo de compilación nativa y se compila en el binario de la aplicación nativa. Si necesita cambiar su configuración de Capacitor, debe:

  1. Actualizar capacitor.config.ts localmente
  2. Recompilar su aplicación nativa (npx cap sync seguido de una compilación nativa)
  3. Enviar el nuevo binario a las tiendas de aplicaciones

Actualmente, Capgo no admite la posibilidad de enviar aplicaciones a las tiendas de aplicaciones en tu nombre. Tenemos planes para agregar esta función en el futuro, pero por ahora, necesitarás seguir utilizando tus procesos existentes para enviar aplicaciones a las tiendas de aplicaciones.

Puedes utilizar nuestro Guía de CI para Android para automatizar este proceso y Guía de CI para iOS.

El actualizador de Capgo (incluso en tu aplicación cuando construyes tu aplicación) almacena la última versión descargada en el único directorio que capacitor permite cargar code. En Android, se encuentra en /data/user/0/com.example.app/code_cache/capgo_updater aunque la base de esa ruta se proporciona por el sistema Android y puede cambiar dinámicamente en tiempo de ejecución. En dispositivos iOS, los datos se almacenan bajo Library/Application Support/capgo.

Los herramientas de línea de comandos Capgo (por ejemplo, npx @capgo/cli@latest bundle upload) se instalan en el disco en cachés npm, sus credenciales de inicio de sesión se almacenan en el directorio de inicio en ~/.capgo.

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

Sección titulada “¿Cómo se relaciona esto con Capacitor Hot Reload?”

El Hot reload de Capacitor es una característica solo disponible en tiempo de desarrollo. Code push es para producción.

El Hot reload es una característica de Capacitor que te permite cambiar code en el dispositivo durante el desarrollo. Requiere construir la aplicación Capacitor con un proxy para conectarse a la máquina local.

Code push es una característica que te permite cambiar code en el dispositivo en producción. Usaremos una variedad de técnicas diferentes para hacer esto posible dependiendo del plataforma.

¿Qué tipos de cambios soporta Capgo code push?

Sección titulada “¿Qué tipos de cambios soporta Capgo code push?”

Capgo can change any JS code in your application. This includes app code and generated code. You can also update dependencies in package.json a menos que requieran cambios nativos de code.

No tenemos planes para apoyar cambios nativos de code (por ejemplo, Java/Kotlin en Android o Objective-C/Swift en iOS), y el herramienta te advertirá si detecta que has cambiado code nativos, ya que no serán incluidos en el paquete.

No se necesita un Code push para web, ya que el web funciona de esta manera. Cuando un usuario abre una aplicación web, descarga la última versión desde el servidor si es necesario.

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

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

Sección titulada “¿Funcionará esto en iOS, Android, Mac, Windows, Linux, etc.?

Sí.

Hasta ahora hemos centrado nuestra atención en el soporte para Android, iOS y Electron, y code está listo para producción en todos los tres.

¿Qué versiones de sistema operativo soporta Capgo?

Sección titulada “¿Qué versiones de sistema operativo soporta Capgo?”

Capgo soporta las mismas versiones de Android que Capacitor soporta.

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

Capgo soporta solo las últimas versiones estable de Capacitor. Podríamos soportar versiones más antiguas de Capacitor también, pero simplemente no hemos construido la infraestructura necesaria para mantenerlas a largo plazo. Tenemos la intención de soportar más versiones de Capacitor en el futuro, incluyendo cualquier versión para nuestros clientes empresariales. https://github.com/Cap-go/capgo/issues/1100

Capgo sigue Capacitor estable y actualiza generalmente dentro de unas pocas horas de cualquier lanzamiento estable. Nuestro sistema para realizar estas actualizaciones es automático y tarda unos minutos en ejecutarse. Luego realizamos un paso adicional de verificación manual antes de publicar en nuestros servidores.

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

Sección titulada “¿Cómo se relaciona esto con el proceso de revisión o políticas de la Tienda de Aplicaciones/Play Store?”

Los desarrolladores están sujetos a sus acuerdos con los proveedores de tiendas cuando eligen utilizar esas tiendas. Code push está diseñado para permitir a los desarrolladores actualizar sus aplicaciones y cumplir con las políticas de las tiendas en los canales de entrega de iOS, Android y Electron. De manera similar a la variedad de productos comerciales disponibles para hacerlo con React Native (por ejemplo, Microsoft, Microsoft también publica una guía sobre cómo su solución cumple con las políticas de las tiendas: ).

https://__CAPGO_KEEP_0__.com/microsoft/react-native-__CAPGO_KEEP_1__-push#store-guideline-compliance github push es una técnica ampliamente utilizada en las tiendas de aplicaciones. Todos los grandes aplicativos que conozco utilizan code push. La política principal a la que debes estar atento es no cambiar el comportamiento de la aplicación de manera significativa. Por favor, consulta

Code push is a widely used technique throughout the app stores. All of the large apps I’m aware of use code push. The major policy to be aware of is not to change the behavior of the app in a significant way. Please see para obtener más información. __CAPGO_KEEP_0__ sigue __CAPGO_KEEP_1__ estable y actualiza generalmente dentro de unas pocas horas de cualquier lanzamiento estable. Nuestro sistema para realizar estas actualizaciones es automático y tarda unos minutos en ejecutarse. Luego realizamos un paso adicional de verificación manual antes de publicar en nuestros servidores.

¿Cumple Capgo con las directrices de la tienda Play?

Sección titulada “¿Cumple Capgo con las directrices de la tienda Play?”

Sí.

La tienda Play ofrece dos restricciones relacionadas con herramientas de actualización.

  1. Las actualizaciones deben utilizar un intérprete o una máquina virtual (Capgo utiliza JavaScript en un WebView). https://support.google.com/googleplay/android-developer/answer/9888379?hl=es
An app distributed via Google Play may not modify, replace, or update itself
using any method other than Google Play's update mechanism. Likewise, an app
may not download executable code (such as dex, JAR, .so files) from a
source other than Google Play. *This restriction does not apply to code
that runs in a virtual machine or an interpreter* where either provides
indirect access to Android APIs (such as JavaScript in a webview or
browser).
Apps or third-party code, like SDKs, with interpreted languages (JavaScript,
Python, Lua, etc.) loaded at run time (for example, not packaged with the
app) must not allow potential violations of Google Play policies.
  1. Los cambios en la aplicación no deben ser engañosos (por ejemplo, cambiar el propósito de la aplicación mediante actualizaciones). https://support.google.com/googleplay/android-developer/answer/9888077 Por favor, sea claro con sus usuarios sobre qué están proporcionando con su aplicación y no violen sus expectativas con cambios de comportamiento significativos a través del uso de Capgo.

Capgo está diseñado para ser compatible con las directrices de la tienda Play. Sin embargo Capgo es una herramienta, y como cualquier herramienta, puede ser abusada. Abusar deliberadamente de Capgo para violar las directrices de la tienda Play es una violación de los Capgo Condiciones de Servicio y puede resultar en la terminación de su cuenta.

Finalmente, code los servicios de empuje son ampliamente utilizados en la industria (todos los grandes aplicativos que conozco los utilizan) y hay varios otros code servicios de empuje disponibles públicamente (por ejemplo, expo.dev y appcenter.ms). Este es un camino bien transitado.

Microsoft también publica una guía sobre cómo su biblioteca de código de react native cumple con las directrices de la tienda de aplicaciones: https://github.com/microsoft/react-native-code-push#directrices-de-compliance-de-la-tienda

¿Cumple Capgo con las directrices de la Tienda de Aplicaciones?

Título de la sección “¿Cumple Capgo con las directrices de la Tienda de Aplicaciones?”

Sí.

De manera similar a la Tienda de Juegos, la Tienda de Aplicaciones ofrece restricciones técnicas y de política.

3.2.2
... interpreted code may be downloaded to an Application but only so long as
such code:
(a) does not change the primary purpose of the Application by providing
features or functionality that are inconsistent with the intended and
advertised purpose of the Application as submitted to the App Store,
(b) does not create a store or storefront for other code or applications, and
(c) does not bypass signing, sandbox, or other security features of the OS.

Capgo utiliza JavaScript en un navegador para cumplir con la restricción de intérprete solo para actualizaciones en iOS. Tan pronto como su aplicación no esté realizando comportamiento engañoso a través de actualizaciones (por ejemplo, cambiar el propósito de la aplicación a través de la actualización), actualizar mediante Capgo (o cualquier otro code solución de empuje) es una práctica estándar de la industria y cumple con las directrices de la Tienda de Aplicaciones.

Abusando deliberadamente Capgo para violar las directrices de la Tienda de Aplicaciones es una violación de los Capgo Términos y Condiciones y puede resultar en la terminación de su cuenta.

Microsoft también publica una guía sobre cómo su biblioteca de código nativo de React 'codepush' cumple con las tiendas de aplicaciones: https://github.com/microsoft/react-native-code-push#compliance-con-los-directrices-de-la-tienda

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

Reconocemos que algunos países tienen restricciones sobre qué URLs se pueden acceder desde dentro del país. Capgo utiliza actualmente Cloudflare Cloud para alojamiento, incluyendo R2 Storage y trabajadores de Cloudflare.

Las siguientes URLs se utilizan por Capgo:

  • https://api.capgo.app – utilizado por las herramientas de línea de comandos para interactuar con los servidores __CAPGO_KEEP_0__ así como con el actualizador __CAPGO_KEEP_1__ en los dispositivos de los usuarios para verificar actualizaciones. npx @capgo/cli command line tools to interact with the Capgo servers as well as the Capgo updater on users’ devices to check for updates.
  • – utilizado por la herramienta de línea de comandos para subir y descargar el paquete Si todas esas URL son accesibles desde tu país, entonces __CAPGO_KEEP_0__ debería funcionar. npx @capgo/cli Si tu región requiere bloquear el acceso a alguna de esas URL, por favor háznoslo saber y podemos trabajar contigo para encontrar una solución. Los servidores de proxy son una opción.

Puedo hospedar Capgo por mí mismo?

Enlace directo a Puedo hospedar __CAPGO_KEEP_0__ por mí mismo?

Sección titulada “Puedo hospedar Capgo por mí mismo?”

https://Capgo.com/cap-go/__CAPGO_KEEP_1__

– utilizado por las herramientas de línea de comandos para interactuar con los servidores Capgo así como con el actualizador code en los dispositivos de los usuarios para verificar actualizaciones. https://github.com/cap-go/capgo

¿code requiere conexión a Internet para funcionar?

Sección titulada “¿code requiere conexión a Internet para funcionar?”

Sí. Podrías imaginar ejecutar un servidor para distribuir las actualizaciones por separado de Internet general, pero se requiere alguna forma de conectividad de red para transportar actualizaciones a los dispositivos.

¿Cómo se ve afectado Capgo por la falta de conectividad de red?

Sección titulada “¿Cómo se ve afectado Capgo por la falta de conectividad de red?”

Capgo actualizador (incluido en tu aplicación cuando construyes tu aplicación con Capgo) está diseñado para ser resistente a problemas de conectividad de red.

En el comportamiento de actualización por defecto, cuando la aplicación se inicia, alerta al actualizador Capgo, que despliega un hilo separado para realizar una solicitud de red a los servidores de Capgo y pedir una actualización. Intencionalmente usamos un hilo separado para evitar afectar cualquier otra cosa que la aplicación pueda estar haciendo. Si la solicitud de red falla o caduca, el actualizador simplemente intentará verificar de nuevo la próxima vez que la aplicación se inicie.

Capgo herramientas de línea de comandos (por ejemplo, Capgo) requieren conectividad de red para funcionar. Si estás utilizando Capgo para distribuir tu aplicación, asegúrate de que tu sistema de CI tenga conectividad de red. npx @capgo/cli@latest bundle upload) require network connectivity to function. If you are using Capgo to distribute your app, you should ensure that your CI system has network connectivity.

__CAPGO_KEEP_0__ command line tools (e.g. __CAPGO_KEEP_0__) require network connectivity to function. If you are using __CAPGO_KEEP_0__ to distribute your app, you should ensure that your CI system has network connectivity.

Sección titulada “¿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 específicamente diseñada para el dispositivo que la está solicitando, actualizando al solicitante siempre a la última versión disponible. Por lo tanto, si un usuario no actualiza durante un tiempo, “se perderán” las actualizaciones intermedias.

El servidor de actualizaciones podría ser modificado para que responda con la versión incremental siguiente o la última versión, dependiendo de las necesidades de su aplicación. Por favor, háznoslo saber si los comportamientos de actualización alternativos son importantes para usted.

Capgo es un plugin para Capacitor que agrega code de empuje. Capgo no es una sustitución para Capacitor. Puede seguir utilizando las herramientas de Capacitor que ya conoce y ama.

Seguimos el último lanzamiento estable de Capacitor y actualizamos nuestro plugin de empuje de code para que funcione con él.

Por defecto, el actualizador Capgo verifica actualizaciones al iniciar la aplicación. Se ejecuta en un hilo de fondo y no bloquea el hilo de la interfaz de usuario. Cualquier actualización se instalará mientras el usuario utiliza la aplicación y se aplicará la próxima vez que la aplicación se reinicie.

También es posible ejecutar manualmente el actualizador Capgo utilizando el @capgo/capacitor-updater paquete, a través del cual es posible desencadenar actualizaciones en cualquier momento, incluyendo a través de una notificación de empuje.

El actualizador Capgo está diseñado de tal manera que cuando no está disponible la red, o el servidor está caído o de otra manera inalcanzable, la aplicación seguirá funcionando de manera normal. Si alguna vez decides eliminar una actualización de nuestros servidores, todos tus clientes seguirán funcionando de manera normal.

Hemos agregado la capacidad de deshacer parches. La cosa más simple es simplemente adjuntar un paquete anterior a tu canal para deshacer.

No. El app_id está incluido en tu aplicación y es seguro que sea público. Puedes verificarlo en el control de versiones (incluso públicamente) y no te preocupes por que alguien más acceda a él.

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

Aunque Capgo se conecta a la red, no envía ninguna información identificativa personal. Incluir Capgo no debe afectar sus declaraciones para la Tienda de Juegos o la Tienda de Aplicaciones.

Las solicitudes enviadas desde la aplicación a los servidores de Capgo incluyen:

  • app_id (especificado capacitor.config.json)
  • canal (opcional en capacitor.config.json)
  • release_version (versiónName desde AndroidManifest.xml o CFBundleShortVersionString desde Info.plist o capacitor.config.json si se establece en CapacitorUpdater.version )
  • version_number (generado como parte de npx @capgo/cli@latest bundle upload)
  • os_version (por ejemplo, ‘11.2.1’)
  • plataforma (por ejemplo, ‘android’, necesaria para enviar el parche correcto) Eso es todo. El code para esto está en updater/library/src/network.rs
  • id del dispositivo (generado en el dispositivo al ejecutarse por primera vez, utilizado para evitar la duplicación de instalaciones por dispositivo y permitirnos cobrar en función de los usuarios instalados (por ejemplo, usuarios activos mensuales), en lugar de parches totales o instalaciones de parches totales)
  • id personalizado (opcional, establecido en tiempo de ejecución por el desarrollador, utilizado para vincular un dispositivo a un usuario en su sistema)

¿Puedo utilizar Capgo para aplicaciones sensibles a HIPAA?

Sección titulada “¿Puedo utilizar Capgo para aplicaciones sensibles a HIPAA?”

Sí, pero su propietario de cumplimiento necesita elegir el modelo de despliegue adecuado. Capgo Cloud no se presenta actualmente como un procesador de estadísticas hospedado HIPAA-compliant. Por defecto, los datos del actualizador están escopados al dispositivo y no están vinculados a un usuario de aplicación conocido, y muchas equipos utilizan ese modelo con éxito.

Para revisiones más estrictas, puede geo-localizar el tráfico del plugin, deshabilitar estadísticas estableciendo statsUrl a una cadena vacía, solo hospedar la estadística de punto final, o utilizar la licencia de autohospedaje. No llame CapacitorUpdater.setCustomId(...) con un correo electrónico, ID de usuario, ID de paciente, ID de empleado o cualquier valor que mapee la telemetría del actualizador hacia una persona.

Consulte Cumplimiento de HIPAA para la configuración técnica completa y los tradeoffs de observabilidad cuando se deshabilitan las estadísticas.

¿Puedo mantener los datos de actualización en vivo de Capgo en Europa?

Sección titulada “¿Puedo mantener los datos de actualización en vivo de Capgo en Europa?”

Sí. Las aplicaciones que necesitan residencia de datos en la UE para el tráfico del plugin de Cloud de Capgo pueden configurar los puntos de conexión del actualizador en el 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

Utilice las tres URL de la UE juntas para que las comprobaciones de actualización, las estadísticas y la asignación de canal se utilicen el mismo camino de ruta de datos regional. Porque estos valores viven en capacitor.config.ts , los aplicaciones móviles de producción necesitan una versión nativa antes de que las instalaciones existentes utilicen los nuevos puntos de conexión.

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

Actualmente, Capgo admite Android, iOS y Electron. Todos son listos para producción.

El uso de Capgo para iOS, Android o Electron puede ser una decisión independiente. Puede configurar su estrategia de canal para Android y un archivo ipa para la Tienda de Mac App, o los canales de Electron, según sea necesario.

Capgo puede (relativamente fácilmente) ser hecho para apoyar objetivos de escritorio o integrados. Si eso es importante para usted, por favor háganoslo saber.

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

Sección titulada “Cómo interactúa Capgo con Play Testing Tracks o Apple TestFlight?”

Cada una de las tiendas de aplicaciones tienen mecanismos separados para distribuir aplicaciones a grupos de usuarios limitados (por ejemplo, “pruebas internas”, “beta cerrado”, etc.). Estos son todos mecanismos para segmentar a los usuarios en grupos y distribuir versiones específicas de las aplicaciones a cada uno.

Desafortunadamente, no todos estos mecanismos permiten a terceros detectar cuando las aplicaciones están instaladas en cualquier pista de prueba específica o a través de TestFlight. Por lo tanto, no tenemos visibilidad confiable en la composición de estos grupos, y no podemos bloquear de manera confiable el acceso a parches de Capgo basados en estos grupos. 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 desea segmentar la disponibilidad del paquete Capgo, hay 4 opciones potenciales:

  1. Utilice un canal separado para cada grupo. Este es el enfoque más directo, pero requiere que gestione múltiples canales. Es posible que ya tenga canales de desarrollo y canales de producción con disponibilidad diferente. Puede actualizar así sus canales de desarrollo, verificarlos y luego actualizar separadamente sus canales de producción. Recomendamos utilizar ramas / etiquetas en su control de versiones para ayudar a mantener el seguimiento de las fuentes asociadas con cada lanzamiento.
  2. Seguir su propio conjunto de usuarios que se han suscrito, deshabilitar las actualizaciones automáticas y activar actualizaciones solo para ciertos usuarios a través del @capgo/capacitor-updater paquete. Esto funciona hoy en día, pero requiere que gestione su propia lista de usuarios que se han suscrito.
  3. Capgo permite crear su propio mecanismo de suscripción en una base por dispositivo (similar a Test Tracks o TestFlight, pero agnóstico de plataforma). Esto permite a su equipo de QA suscribirse al paquete antes de que sean promocionados al público en general.
  4. Capgo tienen rollouts basados en porcentajes. Esto no le permite elegir qué dispositivos enviar, pero puede ayudarlo a desplegar de manera incremental y retroceder en caso de problemas.

Puedes actualizar o descender tu plan en cualquier momento en tu panel de control: https://console.capgo.app/configuración/organización/planes

¿Cuándo se reinicia mi período de facturación?

Sección titulada “¿Cuándo se reinicia mi período de facturación?”

Los períodos de facturación se reinician automáticamente cada mes en el mes en que te suscribiste a Capgo. Por ejemplo, si te suscribiste el 15 de un mes, tu período de facturación se reiniciará el 15 de cada mes.

Puedes cancelar tu suscripción en cualquier momento en tu panel de control: https://console.capgo.app/configuración/organización/planes

Sí, puedes hacerlo en cualquier momento en tu panel de control: https://console.capgo.app/configuración/organización/planes

Las estadísticas en tu panel de control se actualizan cada medianoche UTC. Las estadísticas se calculan con base en el número de MAU que se han instalado en tus dispositivos.

El ID de dispositivo se genera en el dispositivo al primer arranque, y se utiliza para evitar la duplicación de instalaciones por dispositivo y permitirnos cobrar en función de los usuarios instalados (por ejemplo, usuarios activos mensuales), en lugar de parches totales o instalaciones de parches totales.

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

Persistencia de DeviceID (Actualizado en v6.25.0 y v7.25.0):

  • Comportamiento actual: El ID de dispositivo ahora persiste a través de reinstalaciones de aplicaciones. Se almacena de manera segura en el Keychain del dispositivo (iOS) o EncryptedSharedPreferences (Android), lo que nos permite seguir rastreando el mismo dispositivo incluso después de desinstalar/reinstalar.
  • Comportamiento anterior (antes de v6.25.0/v7.25.0): Por razones de privacidad relacionadas con las políticas de Apple y Google Store, el ID de dispositivo se reiniciaba en cada reinstalación de la aplicación, lo que hacía imposible seguir rastreando el mismo dispositivo a través de reinstalaciones.

Las reglas de privacidad se aplican por parte de Apple y Google, y Capgo cumple con sus mejores prácticas para la identificación de dispositivos.

El ID de dispositivo no se incluirá en su lista de dispositivos hasta que obtengan su primer parche instalado.

¿Por qué mi número de dispositivo es diferente a mi MAU?

Sección titulada “¿Por qué mi número de dispositivo es diferente a mi MAU?”

Actualmente, la lista de dispositivos no se actualiza con la frecuencia que el MAU.

La lista de dispositivos se actualiza solo cuando un dispositivo instala una actualización.

Mientras que el MAU se actualiza en cada lanzamiento de la aplicación. Este es una limitación actual del plataforma. Nuestra plataforma de Analytics no soporta actualizaciones brutas, por lo que usamos una base de datos convencional para la lista de dispositivos.

Para limitar el número de consultas a la base de datos, actualizamos solo la fila en la actualización de la aplicación.

Esta limitación se eliminará en el futuro.

Cómo tener actualizaciones diferentes por plataforma?

Sección titulada “Cómo tener actualizaciones diferentes por plataforma?”

Puede crear un canal para cada plataforma y deshabilitar las actualizaciones específicas de plataforma en cada canal.

En el canal de iOS, deshabilite las actualizaciones de Android y en el canal de Android, deshabilite las actualizaciones de iOS.

Luego subir un paquete a cada canal para tener actualizaciones diferentes para cada plataforma.

Si necesita tener la misma actualización para ambas plataformas, puede vincular un paquete a múltiples canales. No es necesario duplicar el paquete.

Si está utilizando FAQ para planificar la entrega de actualizaciones en vivo, conéctelo con Capgo Actualizaciones en vivo para el flujo de trabajo del producto en Capgo Actualizaciones en vivo, Resumen para los detalles de implementación en Resumen, Características para los detalles de implementación en Características Actualizar Comportamiento para los detalles de implementación en Actualizar Comportamiento, y Tipos de Actualización para los detalles de implementación en Tipos de Actualización.