Cuánto tarda la revisión de la App Store

Apple publica una cifra: el 90 % de los envíos se revisan en menos de 24 horas.

Google publica un rango: de unas horas hasta siete días, o más en casos excepcionales, y recomienda planificar al menos una semana de margen entre enviar y publicar.

Esa diferencia explica la mayoría de errores de planificación de releases. La gente planifica con el número de Apple y la pilla el de Google.

Qué significan realmente los estados

Las definiciones de la propia Apple, más precisas de lo que nadie las usa:

Estado	Qué significa
Prepare for Submission	Tienes un registro de app y lo estás rellenando
Ready for Review	Has metido los metadatos y declarado que quieres enviar. No has enviado.
Waiting for Review	Apple tiene tu envío pero no ha empezado
In Review	Alguien lo está mirando. Todavía puedes retirar el build
Metadata Rejected	El build está bien. Algo de la ficha no
Rejected	El envío no ha pasado
Accepted	Este elemento ha pasado, pero otro del mismo envío no. No se publica nada hasta que pase todo
Pending Developer Release	Aprobado. Esperando a que pulses el botón
Processing for Distribution	Aprobado y publicado. En la tienda en 24 horas
Pending Apple Release	Retenido hasta que salga públicamente la versión de sistema correspondiente
Ready for Distribution	Publicado

Dos de estos causan casi toda la confusión. Ready for Review no es enviado. Y Accepted no significa publicado: si enviaste una versión de app junto a otros elementos y uno falló, las partes aceptadas se quedan esperando.

Cuándo tarda más

Apple documenta exactamente una causa: los envíos incompletos. En sus palabras, si tu envío está incompleto, los tiempos de revisión pueden retrasarse o el envío puede no pasar. Más del 40 % de las incidencias sin resolver vienen de la guía 2.1, App Completeness.

Más allá de eso, Apple nombra categorías que reciben más escrutinio, no más tiempo. Las apps médicas que podrían dar datos inexactos o usarse para diagnosticar se revisan con más detalle. Las apps de investigación sanitaria necesitan aprobación de un comité de ética. Las apps de banca, sanidad, apuestas, cannabis, transporte aéreo y exchanges de cripto se espera que las envíe la entidad legal que presta el servicio, no una persona desarrolladora a título individual.

Un límite estructural que conviene planificar: puedes tener una versión de app en revisión por plataforma a la vez, y un máximo de dos envíos en revisión simultáneos. Desde octubre de 2025 puedes mandar otros elementos de forma independiente, así que una corrección crítica ya no tiene que esperar detrás de una página de producto personalizada que sigue en revisión.

Revisión acelerada

Apple la tiene. Google no publica nada equivalente.

Apple concede revisión acelerada por circunstancias atenuantes, y nombra dos: corregir un fallo crítico, o publicar para coincidir con un evento con el que estés directamente asociado.

Qué incluir, según Apple:

• Corrección de fallo: los pasos para reproducir el fallo en la versión actualmente publicada. No una descripción de la corrección. La reproducción.
• Evento: el evento, su fecha y la relación de tu app con él.

Apple también dice que, para un evento, la mejor respuesta es programar la publicación en App Store Connect en lugar de correr contra la revisión. Merece tomárselo en serio: programar no cuesta nada, y acelerar gasta buena voluntad.

Si te rechazan y crees que quien revisó malinterpretó tu app, hay otra vía: una apelación al App Review Board. Una apelación por envío fallido, y responde antes a cualquier petición de información pendiente.

Cuatro creencias que ninguna tienda documenta

Las cuatro se repiten como hechos, incluso por gente que debería saberlo mejor.

"Reenviar te manda al final de la cola." En Google es cierto, y Google lo dice sin rodeos: el tiempo se cuenta desde el último cambio enviado, y tu app puede pasar al final de la cola de revisión. Apple no documenta nada parecido. Lo más cercano que dice Apple es que los envíos pueden no revisarse en el orden en que los mandas.

"Las actualizaciones de solo metadatos van más rápido." Apple no publica tal cosa, y apenas existe algo en lo que ir más rápido. La mayoría de cambios de ficha necesitan una versión nueva, que necesita un build. Las excepciones documentadas son el texto promocional, que puedes cambiar cuando quieras, más la URL de soporte, la URL de marketing, la información de revisión y las notas de versión. Todo lo demás espera a una versión.

"Las cuentas nuevas y los primeros envíos van más lentos." Apple no lo documenta en ninguna parte. Puede que sea cierto. Apple nunca lo ha dicho.

"La revisión de TestFlight es más rápida." Los builds externos de TestFlight sí pasan por una Beta App Review aparte, con sus propios estados y su propia cola. Apple no publica tiempos para ella ni comparación con la revisión de la App Store.

Si planificas un lanzamiento, planifica sobre lo documentado y trata el resto como folclore.

La pregunta de las fiestas

Apple solía cerrar. El último cierre real fue en diciembre de 2020.

Desde entonces sigue abierta y publica en su lugar un aviso a principios de diciembre. El más reciente fue el 2 de diciembre de 2024: se aceptan envíos durante todo el periodo, envía pronto lo que dependa de fechas, las revisiones pueden tardar más del 20 al 26 de diciembre. En 2025 Apple no publicó ningún aviso así.

Así que el consejo honesto es que ya no hay cierre que planificar, pero diciembre sigue siendo el peor mes para dejar una publicación para la última semana.

La puerta aparte de Google

Play tiene un retraso que Apple no tiene, y golpea justo a quien menos se lo espera.

Las cuentas personales de Play Console creadas después del 13 de noviembre de 2023 tienen que hacer una prueba cerrada con al menos 12 testers apuntados de forma continua durante 14 días antes de solicitar acceso a producción. Esa solicitud se revisa por su cuenta, normalmente en siete días.

Para quien publica en solitario por primera vez, eso son dos semanas de pruebas más una de revisión antes de que el reloj normal empiece siquiera a correr. Las comprobaciones previas de Google ayudan a detectar problemas por adelantado y suelen terminar en un cuarto de hora, que es la única parte rápida del flujo de Play.

Números de planificación que puedes usar de verdad

• Apple, actualización rutinaria: cuenta con un día, planifica tres.
• Apple, primer envío: el mismo tiempo de revisión, pero reserva días para lo que falla en la 2.1 antes de llegar ahí.
• Google, cuenta establecida: planifica una semana.
• Google, cuenta personal nueva, primera app: planifica un mes antes de que nada pueda publicarse.
• Cualquier cosa atada a una fecha: programa la publicación en lugar de acelerarla, y envía con al menos dos semanas de margen.

Qué hace Uprate con esto

El agente de envíos caza los bloqueos y te da el campo exacto y la solución antes de que envíes. La revisión más rápida es la que no tienes que hacer dos veces.

Nada se publica hasta que tú lo apruebas.