Skip to main content

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.

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
  • Genera un link/QR.
  • Ábrelo desde Safari en el iPhone.
  • Instala el perfil de configuración que se descarga — esto registra el UDID automáticamente en Expo/Apple.

3. Correr el build

.\scripts\build.ps1 -Env test -Platform ios
  • EAS genera (o reutiliza) el certificado de distribución y un provisioning profile ad hoc que incluye ese dispositivo.
  • El resultado es un .ipa (no .tar.gz).

4. Instalar en el iPhone

  • El build aparece en expo.dev o en el link que EAS imprime en consola al terminar.
  • Abre ese link desde el navegador del iPhone.
  • Toca instalar — no requiere Mac, App Store ni TestFlight.

Notas

  • Solo dispositivos registrados antes de generar el provisioning profile pueden instalar el build.
  • Si el dispositivo se agregó después de un build viejo, puede que necesites regenerar el profile: 
    eas build --clear-provisioning-profile
  • El provisioning profile expira (normalmente ~1 año).

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

  • Cuenta de Apple Developer Program (paga, $99/año) vinculada al proyecto en EAS.
  • App creada en App Store Connect.

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
  • Sube el .ipa más reciente automáticamente a App Store Connect.
  • Espera a que Apple procese el build (aparece en la sección TestFlight de App Store Connect, usualmente en minutos).

5. Agregar testers

  • En App Store Connect → tu app → pestaña TestFlight.
  • Agrega testers por email (grupo interno) o crea un link público de invitación si quieres que cualquiera con el link pueda unirse.
  • Los testers instalan la app TestFlight desde el App Store, y desde ahí instalan tu build usando el link/invitación.

Notas

  • No requiere registrar UDIDs — cualquier tester invitado puede instalar sin configuración previa.
  • Los builds de TestFlight expiran a los 90 días.
  • Testers externos (fuera de tu equipo de Apple Developer) requieren que Apple apruebe el build para "external testing" (revisión ligera, normalmente rápida).

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:

  • Screenshots (por tamaño de dispositivo)
  • Descripción, keywords, categoría
  • Política de privacidad (URL)
  • Clasificación de contenido (age rating)
  • Precio/disponibilidad por país

3. Enviar a revisión

  • Selecciona el build que subiste (paso 1) en la sección Build.
  • Click en Add for Review → Submit for Review.
  • Apple revisa (normalmente 24-48h, puede variar).

4. Publicación

  • Si aprueban, puedes elegir publicación manual (tú decides cuándo sale al público) o automática (sale apenas Apple aprueba) — se configura antes de enviar a revisión.
  • También puedes usar phased release (lanzamiento gradual a % de usuarios en 7 días) para reducir riesgo si algo sale mal.

Notas

  • El número de versión (app.json → version) y el buildNumber deben ser mayores a la última versión publicada — tu script ya incrementa el patch automáticamente, pero revisa que no choque con una versión ya en revisión.
  • Una vez enviado a revisión, no puedes subir un build nuevo sin cancelar el envío anterior.
  • Si tu app usa capacidades especiales (push notifications, in-app purchases, etc.), Apple puede pedir información adicional o rechazar por incumplimiento de guidelines — vale la pena revisar el build en TestFlight primero antes de enviarlo a producción.

¿Cuál usar?

Ad Hoc TestFlightProducció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íasNo expira (versión publicada)
Pasa por revisión de AppleNoLigera (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
Back to top