Tiempo de revisión del App Store: cuánto hay que esperar
Por Mehdi Azizi
Actualizado el , 9 min
Apple revisa el 50 % de las apps en menos de 24 h y el 90 % en menos de 48 h. Lo que de verdad alarga la espera son los rechazos.
En teoría, el tiempo de revisión del App Store es corto: Apple dice que revisa al menos el 50 % de los envíos en menos de 24 horas, y el 90 % en menos de 48 horas. La cifra viene de la página oficial de App Review. Así que, si tu app pasa a la primera, puedes esperar una respuesta en más o menos un día.
El tiempo real se mide de otra forma: es lo que pasa entre tu primer envío y el momento en que la app está a la venta. Y lo que lo dispara casi nunca es la espera en la cola, sino los rechazos. Cada rechazo reinicia un ciclo completo: leer el motivo, corregir, reenviar y volver a esperar. Eso incluye los rechazos automáticos al subir el build, como ITMS-90338. En esta guía te explico qué alarga ese tiempo, cómo manejar un rechazo sin perder días y qué motivos aparecen más seguido en una primera app.
Hablo desde mis propios envíos. Mis apps de iOS, entre ellas Solys (un despertador con minijuegos) y TradaZen (un simulador de trading), están en el App Store, y me rechazaron varias veces en el camino: con Solys y con otras dos apps, Clic y Nolera. Más abajo te detallo los motivos.
Tiempo de revisión del App Store: lo que Apple anuncia de verdad
Cuando tu build ya está subido sin errores automáticos como ITMS-90725 y tu ficha está completa, lo envías a revisión desde App Store Connect. A partir de ahí, tu envío pasa por varios estados: Waiting for Review, In Review y luego aceptado o rechazado. Apple te avisa por correo en cada cambio, y puedes seguir el estado en App Store Connect o en su app para iPhone.
Tres aclaraciones oficiales que sirven para planificar:
- Estas cifras son tendencias, no una garantía: hasta uno de cada diez envíos espera más de 48 horas.
- Los envíos no se revisan necesariamente en el orden en que llegan, aclara la ayuda de App Store Connect.
- Solo puede haber una versión de la app en revisión por plataforma. No puedes apilar varias versiones para “ganar tiempo”.
Una vez aceptada la app, puedes elegir publicarla automáticamente o lanzarla tú mismo. Esta segunda opción vale oro: primero haces que aprueben la app y luego fijas la fecha de lanzamiento cuando ya tienes luz verde.
Lo que alarga la espera
El tiempo rara vez se alarga por culpa de Apple. Casi siempre se alarga por lo que le mandamos.
El primer envío
En una primera versión, Apple revisa todo de una vez: la ficha, las capturas, la clasificación por edad, la política de privacidad, las declaraciones de recopilación de datos, las suscripciones y la app en sí. Cada elemento es una oportunidad de rechazo. No es que la cola sea más larga, es que hay más superficie que revisar. Si nunca has publicado, los pasos a preparar están en publicar una aplicación en el App Store.
Las suscripciones y compras dentro de la app
Si tu app vende una suscripción, hay dos reglas que cambian tu calendario:
- Tu primera suscripción debe enviarse junto con una nueva versión de la app. Está escrito clarísimo en la ayuda sobre compras dentro de la app. Si la app sale sin ella, vas a necesitar una nueva versión para que la aprueben.
- Todos los elementos de un envío deben ser aceptados para que el envío lo sea. Una suscripción rechazada bloquea todo.
La regla 2.1(b) también exige que las compras dentro de la app estén completas, que el revisor pueda verlas y que funcionen. Si alguna no aparece en la app, explica por qué en las notas de revisión. La configuración completa de una suscripción está en suscripciones in-app en iOS.
La cuenta de demostración que falta
Si tu app pide iniciar sesión, las App Review Guidelines exigen una cuenta de demostración activa o un modo demo completo, y servicios de servidor encendidos durante la revisión. Si no pones credenciales en la sección App Review Information de tu versión, el revisor se queda atorado en la pantalla de inicio de sesión, y eso es un rechazo. Acuérdate también de no apagar tu servidor de pruebas durante la revisión.
Los propios rechazos
Es el factor número uno, por mucho. Apple indica que más del 40 % de los problemas sin resolver tienen que ver con la regla 2.1, la que cubre los cierres inesperados, el contenido provisional y la información incompleta. Un rechazo evitado es, como mínimo, un ciclo ganado.
Responder en el Resolution Center
Cuando rechazan un envío, su estado pasa a Unresolved Issues. El mensaje de Apple cita la regla incumplida, muchas veces con una captura de pantalla del problema. Todo pasa en la sección App Review de tu app en App Store Connect, que mucha gente todavía llama Resolution Center.
El procedimiento oficial para responder a App Review:
- En tu app, haz clic en el enlace de problemas sin resolver, arriba en la página.
- Haz clic en Resolve junto al envío.
- Haz clic en Reply to App Review, escribe tu respuesta (4000 caracteres como máximo) y, si hace falta, adjunta una captura o un documento.
Lo que hace que una respuesta funcione:
- Nombra la corrección, no lo que sientes. “La solicitud de calificación ahora aparece después de ganar la demo, adjunto captura” vale más que un largo alegato.
- Adjunta una prueba. Una captura o un video corto de la pantalla corregida te ahorra un ida y vuelta de preguntas.
- Si el rechazo es solo por los metadatos (texto de la ficha, capturas, enlaces, como un rechazo 2.3.10), Apple aclara que puedes reenviar el mismo build después de corregir. No hace falta recompilar.
Apelar, solo si estás seguro
Puedes impugnar un rechazo ante el App Review Board. Apple pide que expliques con precisión por qué la app cumple las reglas, que hagas una sola apelación por envío rechazado y que primero respondas a las solicitudes de información pendientes. Apelar un rechazo merecido solo alarga la espera.
Enviar una corrección rápido
Cuando el motivo está claro, la velocidad sale de la disciplina:
- Corrige el motivo, y solo el motivo. Meter tres novedades en el build corregido es volver a abrir la superficie de revisión.
- Prueba la corrección en las condiciones del revisor. Si es un problema de visualización, eso significa el iPhone más pequeño compatible y el más grande, no solo el tuyo.
- Cuidado con los elementos que quitas. En un envío con problemas sin resolver, la ayuda de Apple aclara que un elemento retirado no se puede volver a agregar al mismo envío, y que cada elemento solo se puede modificar una vez antes de reenviar. Piénsalo antes de borrar una suscripción rechazada.
- Reenvía y luego responde. Una o dos frases objetivas en tu respuesta para decir qué cambió.
¿Y la revisión acelerada? Existe, pero Apple la reserva para dos casos: corregir un bug crítico en una versión ya publicada, con los pasos para reproducirlo, y apps ligadas a un evento con fecha. No es un atajo para una primera publicación que va atrasada.
Los rechazos más comunes en principiantes
Ya conté en detalle mis dos rechazos de Solys en por qué Apple rechaza una app. Aquí van los motivos que de verdad me tocaron, con su número de regla, porque son justo los que acechan a una primera app.
2.1, la app no funciona (Solys). La demo de bienvenida de Solys era imposible de ganar en una pantalla de iPhone pequeña: un paso obligatorio que no se podía superar, así que la app se consideró incompleta. Ya está corregido.
5.6.3, pedir la calificación demasiado pronto (Solys). La calificación del App Store se pedía al principio del onboarding, antes de que la persona hubiera vivido nada en la app. Tiene que llegar después de un momento de valor real.
5.1.1, la política de privacidad desactualizada (Clic). La regla 5.1.1 exige un enlace a la política de privacidad en App Store Connect y dentro de la app, y esa política debe describir con precisión los datos recopilados, para qué se usan y cómo se eliminan. En Clic, la versión publicada en línea no estaba actualizada. Una política que no sigue el ritmo de tu producto basta para que rechacen el envío.
5.1.1, el botón “Permitir” antes de la solicitud del sistema (Nolera). Nolera mostraba una pantalla explicativa antes de pedir acceso a la cámara, con un botón que decía “Permitir”. Las Human Interface Guidelines sobre privacidad son claras: se permite una pantalla antes de la alerta del sistema, pero su botón no debe decir “Permitir” ni nada parecido, porque en ese momento no se está autorizando nada. Apple recomienda “Continuar” o “Siguiente”.
2.3.2, el ícono reutilizado como imagen promocional de la suscripción (Nolera). La regla 2.3.2 regula cómo se promocionan las compras dentro de la app en el App Store: el nombre, la imagen y la descripción deben ser adecuados. En Nolera, la imagen promocional de la suscripción era simplemente el ícono de la app. Hace falta una imagen propia de la compra.
Lo que une estos cinco rechazos: ninguno era un problema de código complejo. Todos se veían al revisar el expediente con los ojos de un revisor. Si acaban de rechazar tu app y el motivo no está claro, el proceso completo está en aplicación rechazada por Apple.
Considerar el tiempo en tu planificación
Unas reglas simples para que la revisión no mueva tu lanzamiento:
- No anuncies una fecha antes de la aceptación. Haz que aprueben la app, elige la publicación manual y luego fija tu fecha.
- Deja un margen de al menos un ciclo de rechazo si es tu primer envío o tu primera suscripción.
- Abre tu cuenta de desarrollador con tiempo si lo haces a través de una empresa: solo el número D-U-N-S puede tardar más de una semana. Todo está explicado en la guía de la cuenta de desarrollador de Apple.
- Revisa tu expediente como un revisor: cuenta de demo, política de privacidad actualizada, privacy manifest completo, pantallas de permisos, imágenes de suscripción y cada pantalla obligatoria en un iPhone pequeño y uno grande.
Si quieres que revisen tu expediente antes de enviarlo
El Apple Review Kit reúne mi checklist previa al envío, mis rechazos de Apple ya corregidos y skills de Claude Code que revisan tu proyecto, tu paywall y tu ficha. No garantiza la aceptación, eso lo decide Apple, pero te ayuda a detectar los motivos de arriba antes de que te cuesten un ciclo.
¿Estás preparando tu primer envío? El diagnóstico gratuito te manda mi checklist antirrechazos de Apple y te dice qué te falta. Si tu app ya está bloqueada, reserva una hora conmigo: leemos juntos el mensaje de Apple por videollamada. Y si todavía la estás construyendo, en la página de inicio te muestro cómo crear tu aplicación móvil pensando en la revisión desde el principio.
Preguntas frecuentes
¿Cuánto tarda la revisión de una app en el App Store?
Apple dice que revisa al menos el 50 % de los envíos en menos de 24 horas, y el 90 % en menos de 48 horas. No es una garantía: algunos tardan más, y no se revisan necesariamente en el orden en que llegan. El tiempo real es lo que pasa entre tu primer envío y la puesta a la venta, y se alarga sobre todo por los rechazos.
¿Qué alarga el tiempo de revisión de una app?
Los rechazos, por mucho: cada uno reinicia un ciclo completo (leer el motivo, corregir, reenviar, volver a esperar). Apple indica que más del 40 % de los problemas sin resolver tienen que ver con la regla 2.1, la de los cierres inesperados, el contenido provisional y la información incompleta. Un primer envío también multiplica las oportunidades de rechazo, porque Apple revisa todo de una vez.
¿Cómo responder a un rechazo del App Store?
En la sección App Review de tu app, abre los problemas sin resolver, haz clic en Resolve y luego en Reply to App Review. Escribe tu respuesta (4000 caracteres como máximo), nombra la corrección en lugar de lo que sientes y adjunta una captura o un video corto. Si el rechazo es solo por los metadatos, puedes reenviar el mismo build después de corregir. Si el motivo no está claro, lee aplicación rechazada por Apple.
¿Se puede pedir a Apple una revisión acelerada?
Sí, la revisión acelerada existe, pero Apple la reserva para dos casos: corregir un bug crítico en una versión ya publicada, con los pasos para reproducirlo, y apps ligadas a un evento con fecha. No es un atajo para una primera publicación que va atrasada.
¿La primera suscripción debe enviarse junto con la app?
Sí, según la ayuda de Apple: tu primera suscripción debe enviarse junto con una nueva versión de la app. Si la app sale sin ella, vas a necesitar una nueva versión para que la aprueben. Para que el envío sea aceptado, todos sus elementos deben serlo: una suscripción rechazada bloquea todo.
¿Cuándo anunciar la fecha de lanzamiento de tu app?
No antes de que Apple acepte la app. Elige la publicación manual: primero haces que aprueben la app y luego fijas la fecha de lanzamiento cuando ya tienes luz verde. Si es tu primer envío o tu primera suscripción, deja también un margen de al menos un ciclo de rechazo.