Distribución de builds VeriX


Builds de VeriX

Builds de VeriX (scripts\build.ps1)

Cómo generar un build de VeriX con versión y nombre de archivo automáticos, para dev, test o prod.

Qué hace este script

build.ps1 es un wrapper alrededor de eas build. Dispara el build en la nube de Expo (los servidores de Expo compilan, no tu máquina — es exactamente lo mismo que correr eas build -p android --profile test a mano), espera a que termine, y descarga el .apk/.aab ya renombrado. No reemplaza nada de tu flujo normal, solo lo automatiza.

eas build --local NO se usa aquí. Si en algún lado ves referencias a builds "locales" en commits viejos de este repo, ya no aplica — el flujo actual es 100% en la nube.

Uso

Desde la raíz del repo (nexus33-app-verix), en PowerShell:

.\scripts\build.ps1 -Env test
.\scripts\build.ps1 -Env dev
.\scripts\build.ps1 -Env prod

Por defecto compila Android. Para iOS:

.\scripts\build.ps1 -Env test -Platform ios

El build en la nube tarda normalmente 15-20+ minutos — el script se queda esperando, no hace falta hacer nada mientras tanto.

Prerrequisitos

No hace falta Android SDK, JDK, ni Xcode instalados — eso lo tiene Expo del lado de sus servidores.

Troubleshooting

An Expo user account is required to proceed / eas build exited with code 1 No hay sesión iniciada en EAS en esta máquina (el script corre con --non-interactive, así que no te va a pedir login solo — falla directo). Soluciónalo con:

npx eas-cli login

y confirma con npx eas-cli whoami. Después vuelve a correr el script normalmente. Ver también la nota sobre app.json más abajo si el build falló después de que la versión ya se bumpeó.

eas : term not recognized Estás intentando correr eas directo en vez de npx eas-cli. El script usa npx eas-cli internamente, así que no necesitas tener eas-cli instalado global — pero si quieres el comando corto disponible en tu terminal: npm install -g eas-cli.

Qué hace el script, paso a paso

  1. Lee la versión actual de app.json (expo.version).
  2. Calcula la siguiente versión — ver "Versionado" abajo.
  3. Escribe la nueva versión en app.json (en disco, sin commit/push — eso lo sigues haciendo tú manualmente, como siempre).
  4. Obtiene el hash corto del commit actual (git rev-parse --short HEAD).
  5. Genera el timestamp del build.
  6. Mapea -Env al perfil real de eas.json: dev→development, test→test, prod→production.
  7. Corre eas build -p <platform> --profile <perfil> --wait (equivalente a hacerlo a mano) y espera a que termine.
  8. Cuando termina, toma el link de descarga que devuelve Expo y baja el archivo a builds\<nombre-generado>.

Si algo falla en cualquier paso, el script se detiene y muestra el error — no deja archivos de build a medias con nombres incorrectos.

⚠️ Ojo con fallos después del paso 3. El bump de versión en app.json ocurre antes de disparar el build (paso 3 vs. paso 7). Si el build falla después de eso — por ejemplo, por no tener sesión iniciada en EAS — app.json queda con la versión ya incrementada en disco, sin build real asociado. Antes de reintentar, revisa git diff app.json: puedes revertirlo (git checkout -- app.json) para no "quemar" un número de versión, o simplemente dejarlo y correr el script de nuevo (no pasa nada grave si el contador salta un número).

Formato del nombre de archivo

VeriX-{env}-{version}-{yyyyMMddHHmm}+{commitHash}.{apk|aab|ipa}

Ejemplo:

VeriX-test-1.0.1-202607241005+7bc21f0.apk
Parte Significado Origen
env dev, test o prod Parámetro -Env
version Versión semántica app.json (expo.version), auto-bumpeada por el script
yyyyMMddHHmm Fecha/hora del build Generado al momento de compilar
commitHash Hash corto del commit actual git rev-parse --short HEAD
Extensión .apk, .aab, .ipa (o .tar.gz en builds de simulador iOS) Tomada del link real que devuelve Expo, no adivinada

prod en Android genera .aab (Android App Bundle, lo que exige Google Play para publicar). dev/test generan .apk (instalable directo en un dispositivo). Esto ya estaba definido en eas.json, el script no lo cambia.

Versionado (app.json → expo.version)

Formato major.minor.patch:

Build # Versión
1 (manual, punto de partida) 1.0.0
2 1.0.1
... ...
20 1.0.19
21 (rollover) 1.1.0

versionCode (Android) / buildNumber (iOS) — campos aparte

Estos no son lo mismo que expo.version de arriba. Son 2 campos separados (uno por plataforma) que las tiendas usan para exigir que cada build subido sea estrictamente más nuevo que el anterior:

Hoy están configurados para auto-incrementarse solo en el perfil production (eas.json → "autoIncrement": true). Cada build de production los sube en 1 automáticamente — EAS los escribe en app.json solo, sin que el script tenga que hacer nada. test/development no los tocan (no lo necesitan: no se suben a las tiendas, y reinstalar un .apk con el mismo versionCode sobre uno viejo funciona bien en Android).

Salida

Los builds quedan en nexus33-app-verix\builds\ (carpeta ignorada por git, ver .gitignore — no se commitean).

Commit del bump de versión

El script deja app.json modificado en disco pero no commitea ni pushea nada. Cuando quieras dejar ese cambio de versión en git, hazlo tú manualmente como siempre (git add app.json, git commit, git push).

Pendiente / no cubierto todavía por este flujo

Distribución de builds Android con EAS — VeriX

A diferencia de iOS, Android no requiere registrar dispositivos ni certificados de por vida — un APK se puede instalar en cualquier teléfono con "orígenes desconocidos" habilitado. Esto hace que el flujo de pruebas sea más simple.

Para generar el build en sí (.apk/.aab) con versión y nombre automáticos, ver BUILD.md (scripts\build.ps1). Esta guía asume que ya tienes ese archivo listo.

Opción A: Test / instalación directa (APK)

Ideal para pruebas rápidas en cualquier dispositivo del equipo, sin pasar por Google Play.

1. Verificar el perfil en eas.json

Para pruebas, el perfil test debe generar un APK (instalable directo), no un AAB (que es exclusivo para Play Store):

"test": {
  "distribution": "internal",
  "android": {
    "buildType": "apk"
  }
}

2. Correr el build

.\scripts\build.ps1 -Env test -Platform android

El resultado es un .apk en la carpeta builds\.

3. Instalar en el dispositivo

Dos formas:

b) Cable USB (si tienes el .apk en la PC)

adb install builds\VeriX-test-<version>.apk

(requiere adb — viene con Android Studio / platform-tools, y el dispositivo con depuración USB activada)

Notas

Opción B: Producción (publicación en Google Play)

1. Requisitos previos

2. Ajustar el perfil de producción en eas.json

Play Store requiere formato AAB (Android App Bundle), no APK:

"production": {
  "distribution": "store",
  "android": {
    "buildType": "app-bundle"
  }
}

3. Generar el build

.\scripts\build.ps1 -Env prod -Platform android

4. Subir el build a Play Console

npx eas-cli submit -p android --latest

Esto sube el .aab automáticamente al track que definas (por defecto, internal — se puede cambiar a alpha, beta o production en eas.json bajo submit.production.android.track).

5. Testing interno en Play Console (recomendado antes de producción)

6. Promover a producción

Notas

¿Cuál usar?

Test (APK directo) Producción (Play Store)
Setup inicial Ninguno Cuenta de Play Console + service account
Requiere registrar dispositivo No No
Formato de build APK AAB
Pasa por revisión de Google No Sí (horas a días)
Ideal para Prueba rápida en cualquier Android Lanzamiento público / testers vía Play Store

Comparación rápida con iOS

Android iOS
Pruebas rápidas APK directo, sin registrar nada Requiere registrar UDID (ad hoc)
Testing con más gente Internal testing track (Play Store) TestFlight
Producción Play Console (AAB) App Store Connect (revisión completa)
Costo de cuenta developer $25 único $99/año

Distribución de builds iOS con EAS — VeriX

Dos formas de instalar un build de prueba en un iPhone físico sin pasar por el simulador.

Para generar el build en sí (.ipa/.tar.gz) con versión y nombre automáticos, ver BUILD.md (scripts\build.ps1). Esta guía asume que ya tienes ese archivo listo.

Opción A: Ad Hoc (directo al dispositivo, sin TestFlight)

Rápido, pero limitado a dispositivos registrados manualmente (máx. 100 UDIDs/año en tu cuenta Apple Developer).

1. Ajustar el perfil en eas.json

"test": {
  "distribution": "internal",
  "ios": {
    "simulator": false
  }
}

2. Registrar el iPhone (obtener su UDID)

npx eas-cli device:create

3. Correr el build

.\scripts\build.ps1 -Env test -Platform ios

4. Instalar en el iPhone

Notas

Opción B: TestFlight

Mejor para testers externos o cuando no quieres registrar UDIDs uno por uno. Pasa por App Store Connect, así que toma un poco más de tiempo (revisión automática, no manual, suele ser minutos-horas).

1. Requisitos previos

2. Ajustar el perfil de build en eas.json

Para TestFlight normalmente se usa el perfil de production (o uno dedicado), con distribución store:

"production": {
  "distribution": "store",
  "ios": {
    "simulator": false
  }
}

3. Generar el build

.\scripts\build.ps1 -Env prod -Platform ios

(o el ambiente que corresponda al perfil que uses para TestFlight)

4. Subir el build a App Store Connect

npx eas-cli submit -p ios --latest

5. Agregar testers

Notas

Opción C: Producción (publicación en App Store)

El build es técnicamente el mismo que para TestFlight (distribution: "store"), pero además de subirlo hay que enviarlo a revisión de Apple y publicarlo.

1. Build y submit (igual que TestFlight, pasos 3-4)

.\scripts\build.ps1 -Env prod -Platform ios
npx eas-cli submit -p ios --latest

Esto sube el .ipa a App Store Connect — mismo build que usarías para TestFlight, solo que ahora lo vas a enviar a revisión en vez de (o además de) dejarlo en testing interno.

2. Completar la ficha en App Store Connect

Antes de enviar a revisión, en App Store Connect → tu app → App Store tab necesitas tener listo:

3. Enviar a revisión

4. Publicación

Notas

¿Cuál usar?

Ad Hoc TestFlight Producción
Setup inicial Rápido Más pasos (App Store Connect) Igual que TestFlight + ficha completa
Requiere registrar UDID Sí No No
Límite de dispositivos 100/año Sin límite práctico Sin límite (público)
Expiración del build ~1 año 90 días No expira (versión publicada)
Pasa por revisión de Apple No Ligera (external testing) Sí (revisión completa, 24-48h)
Ideal para Prueba rápida en 1-2 dispositivos del equipo Testers externos, distribución más amplia Lanzamiento público