Si tu build lleva horas, o incluso días, atascado en "Esperando revisión" dentro de TestFlight, lo más probable es que no hayas hecho nada mal. El build terminó de procesarse y ahora está en la cola de la Revisión de apps beta de Apple, esperando a que una persona del equipo de App Review lo evalúe antes de habilitarlo para tus testers externos. Lo normal es que esa espera vaya de unas horas a 48 horas, aunque durante los atascos de revisión de 2026 muchos desarrolladores vieron builds parados varios días.
Respuesta rápida
"Esperando revisión" significa que tu build ya se procesó y está en la fila de la Revisión de apps beta de Apple, todavía sin que empiece la revisión humana. Para el primer build de una versión, Apple exige una revisión completa antes de que los testers externos puedan instalarlo, según la documentación de App Store Connect. Un rango normal va de unas horas a 48 horas. Si superas las 48 horas sin cambios, deja de reenviar y empieza a documentar el caso para soporte.
Qué significa "Esperando revisión" en TestFlight
"Esperando revisión" es el estado en el que tu build ya pasó el procesamiento y quedó en cola para la Revisión de apps beta, pero un revisor todavía no lo ha abierto. Apple envía los builds a revisión de forma automática en cuanto los agregas a un grupo de testers externos, tal como indica la página oficial de TestFlight. No es un error ni un bloqueo de tu cuenta, es un paso obligatorio del proceso.
La parte que confunde a muchos es que solo el primer build de cada versión necesita una revisión completa. Apple lo dice de forma explícita en su documentación: el primer build que envías requiere una revisión completa, pero los builds posteriores de la misma versión podrían no necesitarla. Por eso el primer envío de una versión nueva casi siempre tarda más que los siguientes.
Conviene distinguir dos tipos de testers, porque no esperan lo mismo. Los testers internos, hasta 100 personas con un rol en tu cuenta de App Store Connect, reciben los builds sin pasar por la Revisión de apps beta, así que para ellos no verás este estado. Los testers externos, en cambio, sí requieren esa revisión, y son ellos los que quedan esperando cuando el build está en cola. Si necesitas probar algo con urgencia, un grupo interno te deja empezar de inmediato mientras el build externo avanza en la fila.
Cuánto tiempo es normal esperar
Lo normal es de unas horas a 48 horas para la Revisión de apps beta, y bastante menos para las compilaciones que no requieren una revisión nueva. Apple no publica un tiempo garantizado, así que cualquier cifra exacta es un promedio observado, no una promesa. Vale la pena separar dos fases que la gente confunde: "Procesando" es la validación automática del binario y suele durar minutos, mientras que "Esperando revisión" es la cola humana y es la que puede tardar horas. La siguiente tabla resume los estados que verás en App Store Connect y cuándo deberías preocuparte.
| Estado en App Store Connect | Qué significa | Rango 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 | Unas horas a 48 horas | Más de 48 horas sin cambios |
| En revisión | Un revisor está evaluando 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 de inmediato |
Durante febrero y marzo de 2026 hubo un atasco notable. En un hilo de los foros de desarrolladores de Apple, decenas de personas reportaron builds de TestFlight parados entre dos y cuatro días, y algunos casos de la App Store llegaron a semanas. El equipo de App Review respondió que creía haber resuelto el problema, pero varios desarrolladores siguieron reportando demoras durante marzo. Lo menciono para que sepas que un atasco largo no siempre es culpa de tu build.
Qué hace que la revisión tarde más
Varios factores alargan la espera, y casi ninguno depende de la calidad de tu código. Los más comunes son la carga de la cola de Apple, el hecho de que sea el primer build de una versión, los cambios grandes que disparan una revisión más cuidadosa, y los problemas de metadatos como una descripción de "qué probar" vacía o permisos que piden justificación. Los envíos hechos justo antes de fechas de mucho volumen, como el inicio de una beta de iOS o las semanas cercanas a un evento de Apple, también tienden a encolarse más.
Hay un detalle técnico que atrapa a mucha gente: solo puedes tener un build de cada versión en revisión a la vez. Si envías un build y luego subes otro de la misma versión, el segundo espera a que el primero termine. Además, Apple limita los envíos a un máximo de seis builds para revisión de TestFlight en un período de 24 horas, según su documentación de testers externos. Subir compilaciones una tras otra no vacía la cola, solo consume ese cupo diario.
Reenviar el build reinicia la espera
No, reenviar rara vez acelera las cosas y a veces las empeora. Como solo puede haber un build de cada versión en revisión al mismo tiempo, subir una compilación nueva de la misma versión no adelanta al que ya está en cola, lo pone detrás. Si en cambio subes una versión distinta, empiezas una revisión completa desde cero, porque el primer build de esa versión nueva vuelve a requerir revisión completa.
En la práctica, lo mejor suele ser dejar el build en su lugar y esperar dentro del rango normal antes de tocar nada. Reenviar tiene sentido solo cuando de verdad corregiste un problema que habría causado un rechazo, no como un intento de empujar la cola. Cada envío innecesario gasta parte de tu cupo de seis builds por día y puede dejarte sin margen si luego sí necesitas subir una corrección real.
Qué hacer, paso a paso
Lo primero es identificar cuánto tiempo llevas esperando y actuar según ese rango, sin reenviar por ansiedad. La siguiente tabla te da una ruta clara según tu situación.
| Tu situación | Qué hacer primero | Cuándo escalar |
|---|---|---|
| Menos de 48 horas en "Esperando revisión" | Esperar, es el rango normal | Todavía no |
| Entre 48 horas y 7 días | Revisar metadatos y "qué probar", confirmar la conformidad de exportación | Prepara un caso para soporte |
| Más de 7 días sin cambios | Contactar a soporte de App Review con capturas y fechas | De inmediato |
| Estado "Rechazado" | Abrir el Centro de resoluciones y leer el motivo exacto | Solo si el motivo es un error de Apple |
| Reenviaste y volvió a la cola | No volver a reenviar, documentar y esperar | Si supera el rango normal otra vez |
Antes de escalar, confirma tres cosas básicas: que la información de conformidad de exportación esté completa, que el campo "qué probar" no esté vacío, y que no tengas otro build de la misma versión bloqueando la cola. Estos tres puntos resuelven una parte grande de los casos que parecen atascos y que en realidad son metadatos incompletos.
Cuándo contactar a soporte de Apple
Contacta a soporte cuando superes con claridad el rango normal, es decir, más de 48 horas sin movimiento y sobre todo pasados varios días. Usa el enlace de contacto de App Review desde App Store Connect y, si el build fue rechazado, responde dentro del Centro de resoluciones, que es el canal que Apple lee para los casos de revisión. Incluye el identificador del build, la fecha y la hora exactas del envío, y una captura del estado.
Ten expectativas realistas. Durante el atasco de 2026, varios desarrolladores reportaron que las solicitudes de revisión acelerada y los correos de soporte quedaron sin respuesta rápida. Escalar es correcto y necesario, pero no garantiza una solución inmediata, así que documenta todo por si el caso se alarga y conviene insistir de forma ordenada.
Antes de reenviar, revisa el build
La forma más segura de no perder tiempo en la cola es no gastar un ciclo de revisión en un build que iba a ser rechazado. Cada rechazo te devuelve al final de la fila, así que un problema evitable, como una clave secreta incrustada en el binario, un permiso sin justificación o una configuración de red insegura, puede costarte otros dos días de espera.
Un escáner de seguridad como PTKD.com analiza el archivo .ipa o .apk antes de subirlo y te devuelve un informe con los hallazgos ordenados por gravedad y mapeados 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 puede acelerar la revisión 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 te obligan a repetir la espera, que es justo el problema cuando ya llevas días atascado.
Puntos clave
- "Esperando revisión" es normal: el build está en la cola de la Revisión de apps beta, no bloqueado ni sancionado.
- El rango normal va de unas horas a 48 horas; pasadas 48 horas sin cambios, deja de reenviar y documenta el caso.
- Reenviar un build de la misma versión no adelanta la cola, porque solo uno puede estar en revisión a la vez.
- Escala a soporte de App Review con identificador, fecha y capturas cuando superes varios días sin movimiento.
- Antes de enviar, revisa el build con PTKD.com para no perder un ciclo de revisión por un rechazo evitable.
