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

Los 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 + Capgo canales

Los primeros dos pueden funcionar, pero crean fricción a largo plazo. En equipos reales, el modelo de canal Capgo suele ser el más limpio.

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

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

• Dos flujos de lanzamiento
• Dos conjuntos de IDs de empuje, enlaces profundos y mapeo de permisos
• Dos identidades de análisis y crash
• Configuración divergente y comportamiento inconsistente entre entornos

Acaba gestionando dos productos a través de consolas de tiendas, equipos y instrucciones de QA internas.

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

El patrón de 'una ID de aplicación + cambio de tiempo de ejecución' suele significar que su aplicación lee variables de entorno o banderas en el arranque y re-ruta APIs, claves y comportamiento de actualización dinámicamente.

Esto funciona hasta:

• Los equipos de QA comienzan a saltarse los flujos previstos porque el estado de configuración está desfasado,
• alguien utiliza el endpoint incorrecto en producción,
• el desplazamiento del entorno causa problemas difíciles de reproducir,
• necesitas 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 los equipos pierden velocidad.

La forma de Capgo : una ID de aplicación, muchos canales

Capgo hace el control del entorno explícito a través de canales:

• Mantén una 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: candidatos internos de QA y lanzamientos
• beta: probadores invitados
• hotfix: pista de parche de emergencia

Su aplicación de prueba interna 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) Baseline de lanzamiento nativo

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 pre-producció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 solo cambios de canal para flujos de trabajo controlados

Para equipos avanzados, expone cambios de canal controlados para usuarios de QA/administración:

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 canales desde la consola y solo cambian el canal para usuarios internos, no para todos los clientes.

Lista de verificación operativa

• Solo un ID de aplicación (sin ID de producción/desarrollo duplicados)
• Una pila de construcción nativa de referencia
• Mapeo de canal documentado (staging, beta, production, hotfix)
• Se aplica el camino de promoción en CI/CD
• Reconstrucción nativa solo en cambios nativos verdaderos
• Se prueba el rollback con regularidad

Beneficio práctico

Esta aproximación elimina la deriva de entorno, reduce la cantidad de construcción y acelera las correcciones:

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

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