Me alegra que hayas preguntado.
No estoy dando consejos legales. Estoy compartiendo lo que es práctico y ampliamente utilizado en equipos que envían aplicaciones Capacitor de manera segura.
La distinción importante es esta:
- La presentación nativa sigue siendo necesaria para nuevos comportamientos nativos y capacidades principales.
- Actualizaciones en vivo son para correcciones y ajustes de JavaScript/web dentro del ámbito de tu aplicación existente.
Puede utilizar este modelo tanto en iOS como en Android, pero debes tratarlo como un y no como una evasión.No es un truco.
¿Qué Apple y Google permiten en términos simples
Puede tratar a Apple y Google como compartiendo una frontera similar:
- Puede entregar code interpretado por la capa web integrada (HTML/CSS/JS) sin volver a enviar.
- No debes alterar controles de seguridad críticos o de distribución mediante JS solo.
- No debes alterar controles de seguridad o distribución críticos mediante JavaScript solo.
Apple’s official guidance around WebKit/JavaScript updates is the core of this model. Google is typically less restrictive for web-based updates, but the same principle applies: keep native changes in a native release.
¿Qué es bueno para Capgo
Capgo es para:
- corregir errores de web
- Correcciones de UI seguras.
- corregir logicas menores en páginas existentes
- realizar pruebas rápidas para la QA interna.
Capgo no es para:
- agregar permisos o nuevas capacidades nativas
- enviar nuevas capacidades core que deben pasar por revisión
- cambiar el comportamiento de firma, cifrado o identidad de paquete.
Estrategia de lanzamiento recomendada
Pensar en dos pistas:
Pista 1: pista nativa (revisión de tienda)
Utilice su proceso de liberación normal Capacitor para:
- actualizaciones de nuevos plugins,
- cambios en la corteza de la aplicación o en el manifiesto
- actualizaciones de permisos,
- cambios de funcionalidad específica de plataforma.
Estos requieren:
bun run build
bunx cap sync
# then App Store / Google Play submission flow
Track 2: Pista de JS (Capgo)
Para cambios de tiempo de ejecución seguros y pequeños:
bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production
Esto le da una iteración rápida sin subir nuevos archivos binarios mientras mantiene el binario estable.
Cómo evitar 'oops, esto necesitaba una liberación nativa'
Antes de cada liberación Capgo, ejecute esta puerta rápida:
- ¿El cambio requiere una nueva dependencia nativa o permiso?
- ¿Cambia las capacidades publicitarias de la aplicación?
- ¿Modifica los límites de autenticación y seguridad?
- ¿Podemos describirla como una corrección no interrumpida de JavaScript?
Si la respuesta es sí a (1)-(3), envíe una versión nativa. Si sí solo a (4), envíe a través de Capgo.
¿Qué significa esto para los equipos de cumplimiento?
- Mantén la banda ancha de revisión de aplicaciones para cambios significativos.
- Usted preserva el control de rollback y parches rápidos.
- Usted reduce el riesgo de producción al probar actualizaciones en canales antes de un lanzamiento completo.
Esto es el mismo enfoque que las personas utilizan en grandes programas Capacitor en producción: actualizaciones rápidas para correcciones de JavaScript únicamente, revisión nativa solo para binarios reales.
Si desea profundizar, pair esto con una estrategia de entorno estricta basada en canales para que la QA nunca reciba errores de producción. Eso es la forma Capgo-nativa de mantener limpios el staging, la beta y la producción.
Siga adelante desde Cómo actualizar aplicaciones Capacitor de JavaScript sin revisión de tienda repetida.
Si está utilizando How to update Capacitor aplicaciones JS sin revisión de tienda repetida para planificar la aprobación y distribución de la tienda, conecte con @capgo/capacitor-revisión en la aplicación para el detalle de implementación en @capgo/capacitor-revisión en la aplicación Usando @capgo/capacitor-revisión en la aplicación para la capacidad nativa en Usando @capgo/capacitor-revisión en la aplicación, @capgo/capacitor-mercado nativo para los detalles de implementación en @capgo/capacitor-mercado nativo, Usando @capgo/capacitor-mercado nativo para la capacidad nativa en Usando @capgo/capacitor-mercado nativo, y Capacitor OTA Updates: App Store Approval Guide para el contexto práctico en Capacitor Actualizaciones OTA: Guía de Aprobación de la Tienda de Aplicaciones.