Capgo Prácticas recomendadas para el entorno: Etapa con un ID de aplicación móvil

Las equipos suelen elegir uno de tres enfoques para entornos móviles:

1. Dos IDs de aplicación (producción + preproducción)
2. Un ID de aplicación + cambio dinámico del entorno de tiempo de ejecución
3. Un ID de aplicación + canales de Capgo

Los primeros dos pueden funcionar, pero crean fricciones a largo plazo. En equipos reales, el modelo de canal Capgo es usualmente el más limpio.

Por qué los IDs de aplicación duplicados se vuelven ruidosos

Usando com.myapp y com.myapp.beta parece simple, pero pronto se produce duplicación:

• Dos líneas de liberación
• Dos conjuntos de IDs de empuje, enlaces profundos y mapeo de permisos
• Dos identidades de análisis y crash
• Diferentes configuraciones y comportamientos inconsistentes entre entornos

Acaba manejando dos productos en consolas de tienda, equipos y instrucciones de QA interna.

Por qué cambiar la configuración en tiempo de ejecución suele ser desordenado

El patrón 'un ID de aplicación + cambio de tiempo de ejecución' usualmente significa que tu aplicación lee variables de entorno o banderas al iniciar y re-ruta APIs, claves y comportamiento de actualización dinámicamente.

Esto funciona hasta:

• El QA comienza a saltarse los flujos previstos porque el estado de configuración está desactualizado
• Alguien utiliza el endpoint incorrecto en producción
• El desfase de entorno causa problemas difíciles de reproducir
• Es necesario depurar “¿qué versión de configuración está utilizando este binario?” en un dispositivo del usuario

Esa complejidad crece con cada lanzamiento y es donde las equipos pierden velocidad

The Capgo way: one app ID, many channels

Capgo makes environment control explicit through channels:

• Mantén una sola ID de aplicación de producción en App Store / Play
• Envía un binario nativo para la “cáscara” (hasta que los cambios nativos requieran una verdadera reconstrucción)
• Ruta el comportamiento por canal, no por la identidad duplicada de la aplicación

En la práctica, esto significa:

• production: todos los usuarios
• staging: pruebas internas y candidatos a la versión de lanzamiento
• beta: probadores invitados
• hotfix: pista de parche de emergencia

Su aplicación de prueba interna de TestFlight/Play puede permanecer en staging para siempre. Puede realizar actualizaciones de JS/CSS/activos allí repetidamente a través de Capgo sin publicar una nueva aplicación nativa.

Estructura recomendada en la práctica

1) Línea base de lanzamiento nativa

Su último binario nativo permanece igual durante muchas iteraciones de JS:

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

Solo reconstruye el binario nativo cuando realmente cambió la superficie nativa.

2) Utilice canales dedicados para entornos

Publica actualizaciones con canales:

bun run build
bunx @capgo/cli deploy --channel staging

Prueba en QA, corrige problemas, luego promueve:

bunx @capgo/cli promote vX.Y.Z --channel production

Si prefieres una versión explícita:

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) Mantén TestFlight “siempre pre-prod”

En flujos de trabajo de iOS, esto significa que tu compilación de TestFlight puede permanecer asociada con actualizaciones de preproducción:

• No hay presentaciones nativas frecuentes para cada cambio de JS.
• QA siempre valida cerca de la producción code a través del canal de staging.
• Los usuarios de producción solo reciben paquetes de canal de producción promocionados.

4) Utiliza el cambio de canal solo para flujos de trabajo controlados

Para equipos avanzados, expone cambios de canal controlados para usuarios QA/admin:

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

Esto es opcional. La mayoría de los equipos utilizan asignaciones de canal desde la consola y solo cambian el canal para usuarios internos, no para todos los clientes.

Lista de verificación operativa

• Sólo un ID de aplicación (sin IDs de producción/staging duplicados)
• Una línea base de pipeline de compilación nativa
• La asignación de canales documentada (staging, beta, production, hotfix)
• El camino de promoción se ve obligado a cumplir en CI/CD
• Recompilar nativa solo en cambios nativos verdaderos
• Se prueba el reenvío con regularidad

Beneficio práctico

Esta aproximación elimina la deriva del entorno, reduce la rotación de compilación y acelera las correcciones:

• La QA obtiene binarios realistas (sin identidad de aplicación ficticia “de staging”),
• Tu camino de TestFlight permanece estable,
• Tu equipo evita la ‘deuda de ID de aplicación’
• Puedes enviar muchas correcciones de JS a través de Capgo de manera rápida.

El resultado final es una gobernanza más simple: menos artefactos, telemetría más limpia y menos sorpresas en las operaciones de lanzamiento.

Continúa desde Capgo Prácticas recomendadas del entorno: Etapa con un ID de aplicación móvil único

Si estás utilizando Capgo Prácticas recomendadas del entorno: Etapa con un ID de aplicación móvil único para planificar la ruta de canales y el lanzamiento en etapa, conecta con Canal contexto: nombre de la característica de canales de Capgo. Página/área: página de marketing de soluciones de Capgo. Rol: etiqueta de IU corta o elemento de navegación. Visto en: página soluciones/white-label.astro. Clave de mensaje `solutions_white_label_visual_cell2_value` (Valor de celda visual de soluciones White Label). para los detalles de implementación en Canal Canal contexto: nombre de la característica de canales de Capgo. Página/área: página de marketing de soluciones de Capgo. Rol: etiqueta de IU corta o elemento de navegación. Visto en: página soluciones/white-label.astro. Clave de mensaje `solutions_white_label_visual_cell2_value` (Valor de celda visual de soluciones White Label). para los detalles de implementación en Canal Canal contexto: nombre de la característica de canales de Capgo. Página/área: página de marketing de soluciones de Capgo. Rol: etiqueta de IU corta o elemento de navegación. Visto en: página soluciones/white-label.astro. Clave de mensaje `solutions_white_label_visual_cell2_value` (Valor de celda visual de soluciones White Label). Solución de Enfoque de Versión para el flujo de trabajo del producto en Solución de Enfoque de Versión.