"Esperando revisión" en TestFlight significa que tu build está en la cola de la Revisión de apps beta de Apple, esperando a que un revisor lo evalúe antes de que tus testers externos puedan instalarlo. Aparece solo con testers externos: los internos no pasan por esta revisión y reciben el build en minutos. Es un paso obligatorio, no un error ni un bloqueo de tu cuenta. Lo normal es esperar de unas horas a 48 horas para el primer build de una versión.
Respuesta rápida
"Esperando revisión" quiere decir que tu build ya se procesó y está en la fila de la Revisión de apps beta, todavía sin que empiece la revisión humana. Apple envía los builds a revisión de forma automática al agregarlos a un grupo externo, según su página de TestFlight, y solo los testers externos requieren esa revisión. La prueba interna no la necesita. Lo normal es de unas horas a 48 horas. Reenviar reinicia la revisión. Si superas 48 horas sin cambios, revisa los detalles y contacta a soporte.
¿Qué significa "Esperando revisión" en TestFlight?
"Esperando revisión" es el estado en el que tu build pasó el procesamiento y quedó en cola para la Revisión de apps beta, pero un revisor aún no lo ha abierto. No es un fallo ni una sanción: es el paso obligatorio para distribuir a testers externos. Apple lo envía a revisión automáticamente cuando agregas el build a un grupo externo.
La parte que confunde a muchos es que solo el primer build de cada versión necesita una revisión completa. Los builds posteriores de la misma versión pueden no necesitarla. Por eso el primer envío de una versión nueva casi siempre tarda más que los siguientes, y una pequeña corrección sobre una versión ya aprobada suele pasar mucho más rápido. Saber esto cambia cómo planificas: si tienes una fecha de prueba comprometida, conviene subir el primer build de la versión con margen y dejar las correcciones menores para después.
¿Por qué la prueba externa requiere revisión y la interna no?
La prueba externa requiere revisión porque distribuye tu app a personas fuera de tu equipo, y Apple revisa ese contenido antes de que llegue a ellas. Los testers internos, hasta 100 personas con un rol en tu cuenta de App Store Connect, son parte de tu organización y reciben el build sin pasar por la Revisión de apps beta. Los testers externos, hasta 10.000 personas, sí requieren esa revisión.
Esta diferencia es útil en la práctica. Si necesitas probar algo con urgencia mientras esperas la revisión externa, agrega a alguien como tester interno y prueba el mismo build de inmediato. Muchos desarrolladores esperan días por la revisión externa cuando un grupo interno habría desbloqueado su propia prueba en minutos. La regla es simple: interno para probar rápido dentro del equipo, externo para recoger opiniones de usuarios reales antes del lanzamiento.
¿Cuánto tarda la Revisión de apps beta?
Lo normal es de unas horas a 48 horas para el primer build de una versión, y suele ser más rápido para los builds posteriores que no requieren una revisión nueva. Apple no garantiza un tiempo, así que cualquier cifra es un promedio, no una promesa. La tabla siguiente resume los estados que verás y cuándo preocuparte.
| Estado | Qué significa | Tiempo normal | Señal de alarma |
|---|---|---|---|
| Procesando | Apple valida el binario subido | Minutos a 1 hora | Más de 2 horas sin avanzar |
| Esperando revisión | En cola para la Revisión de apps beta | Horas a 48 horas | Más de 48 horas sin cambios |
| En revisión | Un revisor evalúa el build | Minutos a unas horas | Más de 24 horas en este estado |
| Listo para probar | Aprobado y disponible para testers | Estado final correcto | (ninguna) |
| Rechazado | Apple encontró un problema | Requiere acción tuya | Revisa el Centro de resoluciones |
En febrero y marzo de 2026 hubo un atasco general que alargó la cola para muchos desarrolladores, según un hilo de los foros de Apple. En esos periodos, una espera larga no siempre significa un problema en tu build, aunque pasadas 48 horas conviene revisar los detalles del envío.
¿Por qué se queda en "Esperando revisión"?
La causa más común es simplemente que es el primer build de una versión, que siempre requiere una revisión completa. Además, Apple solo revisa un build de cada versión a la vez, así que si subes otro de la misma versión, este espera a que el primero termine. También hay un límite de seis builds para revisión de TestFlight en un período de 24 horas.
Los detalles del envío también influyen. Un campo "qué probar" vacío, permisos sin justificación o la conformidad de exportación sin completar pueden alargar la revisión o provocar un rechazo. Rellenar estos campos con claridad antes de enviar es la forma más simple de mantener el build en movimiento hacia el estado "Listo para probar".
¿Reenviar reinicia la revisión?
Sí. Subir un build nuevo de la misma versión reemplaza al que está en revisión y reinicia el proceso desde cero, así que pierdes el progreso y el lugar en la cola. Reenviar solo tiene sentido si corregiste un problema real que habría causado un rechazo, por ejemplo tras leer el motivo en el Centro de resoluciones.
Lo más tranquilo es dejar el build en su sitio y esperar dentro del rango normal. Si necesitas probar de inmediato, recuerda que el canal interno no pasa por la revisión y te da acceso al instante, sin gastar tu cupo de seis builds por día.
Qué hacer, paso a paso
Actúa según cuánto tiempo lleves esperando, sin reenviar por ansiedad. La tabla siguiente da una ruta clara según tu situación.
| Tu situación | Qué hacer primero | Cuándo escalar |
|---|---|---|
| Menos de 48 horas | Esperar, es el rango normal | Todavía no |
| Necesitas probar ya | Usar un grupo de testers internos | No hace falta |
| Otro build de la misma versión en revisión | Esperar a que termine, no apilar envíos | No |
| Más de 48 horas sin cambios | Revisar "qué probar" y la conformidad de exportación | Prepara un caso |
| Estado "Rechazado" | Leer el motivo y corregir | Si el motivo parece un error |
Antes de escalar, confirma que la conformidad de exportación está completa, que el campo "qué probar" no está vacío, y que no tienes otro build de la misma versión bloqueando la cola. Estos tres puntos resuelven una parte grande de los casos que parecen atascos pero son, en realidad, un dato que falta de tu lado.
¿Cuándo contactar a soporte?
Contacta a soporte cuando superes con claridad 48 horas sin movimiento, y sobre todo pasados varios días. Para un rechazo, responde en el Centro de resoluciones. Incluye el identificador del build, la fecha y la hora del envío y una captura del estado, para que tu caso no se retrase por falta de datos.
Ten expectativas realistas: durante el atasco de 2026, el soporte tardó en responder. Escalar es correcto tras varios días, pero no garantiza un desbloqueo inmediato, sobre todo si la causa es un atasco general y no un problema propio de tu build. Aun así, dejar constancia por escrito ayuda si el caso se alarga, porque el equipo de soporte puede retomar el hilo con todos los datos a la vista en lugar de pedírtelos de nuevo.
Antes de enviar, revisa el build
La forma más segura de no perder tiempo es no gastar un ciclo de revisión en un build que iba a ser rechazado. Cada rechazo te devuelve a la cola, así que un problema evitable, como una clave secreta incrustada, un permiso sin justificación o una configuración de red insegura, puede costarte otro ciclo completo justo cuando un equipo espera la beta.
Un escáner de seguridad como PTKD.com analiza el .ipa antes de subirlo y devuelve un informe ordenado por gravedad y mapeado a OWASP MASVS, para que corrijas lo que dispararía un rechazo antes de entrar a la cola. Conviene ser honesto sobre su límite: un escáner no acelera la Revisión de apps beta de Apple ni sustituye una auditoría manual en apps de alto riesgo o reguladas. Lo que sí hace es evitar los rechazos previsibles que repiten la espera, que es justo lo que quieres cuando la revisión ya va lenta.
Puntos clave
- "Esperando revisión" es la cola de la Revisión de apps beta, obligatoria para testers externos, no para internos.
- La prueba externa requiere revisión porque distribuye a personas fuera de tu equipo; la interna no.
- El primer build de una versión necesita revisión completa, normalmente de unas horas a 48 horas.
- Reenviar reinicia la revisión; para probar ya, usa un grupo interno que la omite.
- Antes de enviar, revisa el build con PTKD.com para no perder un ciclo por un rechazo evitable.
