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

Las equipos suelen elegir una de las tres opciones para los entornos móviles:

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

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

Why duplicated app IDs become noisy

Usando com.myapp y com.myapp.beta se siente simple, pero pronto obtienes duplicación:

• Dos líneas de producción
• 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

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

Por qué la configuración de tiempo de ejecución cambia a menudo

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

Esto funciona hasta que:

• QA starts bypassing intended flows because config state is stale,
• Alguien utiliza el endpoint incorrecto en producción
• drift de entorno causa problemas de difícil reproducción.
• Debes depurar ‘¿qué versión de configuración está utilizando este binario?’ en un dispositivo de usuario.

Que esa complejidad crece con cada lanzamiento y es donde los equipos pierden velocidad.

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

Capgo hace explícita la control de entornos mediante canales:

• Mantenga una sola ID de aplicación de producción en App Store / Play.
• Envíe una sola binaria nativa para la "cáscara" (hasta que los cambios nativos requieran una verdadera reconstrucción).
• Comportamiento de ruta por canal, no por identidad de aplicación duplicada.

En la práctica, esto significa:

• productionTodos los usuarios
• staging: QA y candidatos de lanzamiento internos
• beta: probadores invitados
• hotfix: pista de parche de emergencia

Su aplicación de prueba interna de TestFlight/Play puede seguir en staging para siempre. Realiza 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

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

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

Sólo reconstruye el binario nativo cuando realmente cambió el área de superficie nativa.

2) Utiliza 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 iOS, esto significa que su build de TestFlight puede mantenerse asociada con actualizaciones de preproducción.

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

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

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

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

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

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

Lista de verificación operativa

• Sólo un ID de aplicación (sin ID de producción/duplicado de staging)
• Sólo una pila de construcción nativa de base
• La asignación de canales documentada (staging, beta, production, hotfix)
• La ruta de promoción se aplica en CI/CD
• Reconstrucción nativa solo en cambios nativos verdaderos
• Se prueba el retroceso con regularidad

Beneficio práctico

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

• Los QA obtienen binarios realistas (sin identidad de aplicación de "staging" falsa).
• tu camino de TestFlight permanece estable,
• tu equipo evita la ‘deuda de dos 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.

Sigue adelante desde Capgo Prácticas de Entorno: Staging con Un ID de Aplicación Móvil

Si estás utilizando Capgo Prácticas de Entorno: Staging con Un ID de Aplicación Móvil para planificar la ruta de canales y el lanzamiento escalonado, conecta con Canalización para los detalles de implementación en los canales, Canales para los detalles de implementación en los canales, Canales para los detalles de implementación en los canales, Solución de Pruebas Beta para el flujo de trabajo del producto en la Solución de Pruebas Beta Solución de Enfoque en Versión para el flujo de trabajo del producto en la Solución de Enfoque en Versión.