Mejores prácticas del entorno Capgo: staging con un solo Mobile App ID

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

1. Dos app IDs (producción + preproducción)
2. Un app ID + cambio dinámico de entorno en runtime
3. Un app ID + canales Capgo

Las dos primeras pueden funcionar, pero generan fricción a largo plazo. En equipos reales, el modelo de canales de Capgo suele ser el más limpio.

Por qué los IDs de app duplicados generan ruido

Uso de com.myapp y com.myapp.beta parece sencillo, pero pronto aparecen duplicaciones:

• Dos pipelines de release
• Dos sets de push IDs, deep links y mapeo de entitlements
• Dos identidades de analytics y crash reporting
• Configuraciones divergentes y comportamiento inconsistente entre entornos

Terminas gestionando dos productos en las consolas de las tiendas, equipos e instrucciones de QA interno.

Por qué cambiar la configuración en runtime suele ser un caos

El patrón de “un ID de app + switch en runtime” suele implicar que tu app lee variables de entorno o flags al arrancar y redirige APIs, keys y el comportamiento de updates dinámicamente.

Esto funciona hasta que:

• QA empieza a saltarse los flujos previstos porque el estado de la config es antiguo,
• alguien usa el endpoint incorrecto en producción,
• el drift de entornos causa bugs difíciles de reproducir,
• necesitas debuguear “¿qué versión de config usa este binario?” en el dispositivo de un usuario.

Esa complejidad crece con cada release y es donde los equipos pierden velocidad.

El método Capgo: un app ID, muchos canales

Capgo permite un control de entornos explícito mediante canales:

• Mantén un único app ID de producción en App Store / Play.
• Envía un único binario nativo para el “shell” (hasta que cambios nativos requieran un rebuild real).
• Rutea el comportamiento por canal, no duplicando la identidad de la app.

En la práctica, esto significa:

• production: all users
• staging: QA interno y release candidates
• beta: testers invitados
• hotfix: track de parches de emergencia

Tu app de internal testing de TestFlight/Play puede seguir activa staging para siempre. Haces updates de JS/CSS/assets ahí repetidamente con Capgo sin publicar una nueva app nativa.

Estructura recomendada en la práctica

1) Baseline de la release nativa

Tu último binario nativo se mantiene igual durante muchas iteraciones de JS:

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

Solo reconstruyes el binario nativo cuando realmente cambias la superficie nativa.

2) Usa canales dedicados para entornos

Publica updates con canales:

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

Prueba en QA, corrige errores y luego promociona:

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

Si prefieres un versionado explícito:

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

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

En flujos de iOS, esto significa que tu build de TestFlight puede seguir asociado a actualizaciones de pre-producción:

• Sin envíos nativos frecuentes por cada cambio en JS.
• QA siempre valida code cercanos a producción vía el canal de staging.
• Los usuarios de producción solo reciben bundles del canal de producción promocionados.

4) Usa el cambio de canal solo para flujos controlados

Para equipos avanzados, expón cambios de canal controlados para usuarios de QA/admin:

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

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

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

Checklist operativo

• Un solo app ID (sin IDs duplicados de producción/staging)
• Un pipeline de Native Build base
• Mapeo de canales documentado (staging, beta, production, hotfix)
• Flujo de promoción en CI/CD
• Rebuild nativo solo en cambios reales
• Rollback probado regularmente

Beneficio práctico

Este enfoque evita el drift de entornos, reduce el build churn y acelera los fixes:

• QA recibe binarios reales (sin identidades de "app de staging" falsas),
• tu flujo de TestFlight se mantiene estable,
• tu equipo evita la "deuda de dos App IDs",
• puedes lanzar muchos fixes de JS vía Capgo rápidamente.

El resultado es un gobierno más simple: menos artifacts, telemetría limpia y menos sorpresas en el release.

Continuamos con Capgo Mejores prácticas de entornos: Staging con un único App ID

Si estás usando Mejores prácticas del entorno Capgo: staging con un solo Mobile App ID para planificar el enrutamiento de canales y el despliegue gradual, conéctalo con Canales para el detalle de implementación en Channels, Canales para el detalle de implementación en Channels, Canales para el detalle de implementación en Channels, Solución de beta testing para el flujo de trabajo del producto en Beta Testing Solution, y Solución de Version Targeting para el flujo de trabajo del producto en Version Targeting Solution.