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, verBUILD.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
- 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
.ipamá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 elbuildNumberdeben 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 | 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 |
No comments to display
No comments to display