¿Por qué la revisión de la app está tardando tanto?

Una revisión lenta no significa automáticamente que tu app tenga un problema. Aprende a distinguir un retraso en la cola de un envío bloqueado, qué prometen realmente Apple y Google, y cuándo contactar al soporte.

Has subido la compilación, revisado las capturas de pantalla y planificado tu lanzamiento. Luego no pasa nada. App Store Connect sigue diciendo "En espera de revisión", o Play Console mantiene tus cambios en revisión. Mientras tanto, cada día de incertidumbre dificulta coordinar el marketing, la atención al cliente y el anuncio de lanzamiento.

La parte frustrante es que un retraso tiene varias explicaciones posibles. Su envío podría simplemente estar esperando su turno. Un revisor podría necesitar información. Es posible que su compilación no haya llegado a revisión en absoluto. O la revisión podría ya haber terminado, con la publicación esperando por usted. Esta guía explica cómo distinguir esas situaciones. Se centra en Apple App Review, con una comparación separada de Google Play. Las fuentes se verificaron el 3 de octubre de 2026.

¿Cuánto debería tardar la revisión de una aplicación?

Apple dice que, en promedio, el 90% de los envíos se revisan en menos de 24 horas. Eso es un contexto útil, pero no es un tiempo de respuesta garantizado para tu app individual. Algunos envíos caen fuera de esa ventana, y la estadística no te da un tiempo de finalización para esas excepciones. Apple también advierte que los envíos incompletos pueden retrasar la revisión. [1]

Trate ese número como una referencia de planificación, no como un compromiso de lanzamiento. Un envío que tarda más de un día no es, por sí mismo, evidencia de rechazo o de una cuenta rota. Igualmente, un promedio no debería persuadirlo de ignorar un mensaje procesable. El estado y la correspondencia del revisor importan más que las comparaciones con la aprobación más rápida de otro desarrollador.

Primero, identifica dónde está realmente el retraso

Lee el estado preciso en lugar de traducir cada indicador amarillo a "Apple está revisando mi aplicación". Esperando revisión significa que el envío está en cola; En revisión significa que la revisión ha comenzado. Pendiente de lanzamiento del desarrollador significa que la aplicación ha sido aceptada pero aún necesita tu acción de lanzamiento. Esperando cumplimiento de exportación es un proceso diferente. Un elemento aceptado también puede permanecer sin publicar si otro elemento de su envío fue rechazado. [2]

Comprueba la versión de la app y el envío juntos, no solo la compilación subida. Una captura de pantalla de la lista de compilaciones puede contar una historia diferente a la página de envío. Anota la versión, el número de compilación, la hora de envío y el estado actual. Ese pequeño registro evita que soluciones problemas de una compilación antigua o confundas un envío de TestFlight con un lanzamiento en la App Store.

Los revisores necesitan experimentar la aplicación completa

Un revisor no puede evaluar una función a la que no puede acceder. La lista de verificación de envío de Apple pide acceso completo, una cuenta de demostración activa o un modo de demostración apropiado, hardware necesario o recursos de muestra, y servicios backend en vivo. También pide a los desarrolladores que expliquen funciones y compras no obvias en las notas de revisión. Estos requisitos hacen que el acceso sea un primer lugar sensato para investigar. [3]

Pruebe las credenciales exactas que proporcionó, preferiblemente en un dispositivo limpio. Verifique si una cuenta necesita verificación por correo electrónico, un derecho de pago, una invitación o una contraseña de un solo uso. Pruebe la ruta de incorporación sin su cuenta de desarrollo. Si una función requiere una región particular o un segundo usuario, explique cómo el revisor puede reproducir esa configuración. No asuma que inferirán su flujo de trabajo previsto.

Una guía breve y reproducible es más útil que un discurso de ventas. Por ejemplo: inicia sesión con la cuenta proporcionada, abre Biblioteca, selecciona el proyecto de muestra y toca Exportar. Incluye cualquier limitación esperada y explica por qué existe. Esto no compra prioridad; reduce la ambigüedad evitable cuando alguien llega a tu envío.

Un rechazo necesita una respuesta, no más espera

Cuando Apple rechaza una app, su mensaje explica el problema y la directriz relevante. App Store Connect te permite responder y adjuntar material de apoyo. Apple también indica que un rechazo de metadatos puede resolverse y reenviarse usando la misma compilación. Por lo tanto, no siempre es necesario un binario nuevo. [4]

Responda a la objeción específica. Si el revisor no pudo encontrar una función, proporcione los pasos de navegación. Si su preocupación es una captura de pantalla engañosa, corríjala. Si no está de acuerdo, explique el comportamiento y proporcione evidencia en lugar de repetir que las aplicaciones de la competencia lo hacen. Separe lo que cambió de lo que le pide a Apple que aclare.

Mantén un registro de problemas simple: la pregunta del revisor, tu respuesta, el activo o compilación modificado y la siguiente acción requerida. Eso hace que la correspondencia posterior sea más fácil de seguir. También evita que un equipo envíe de forma independiente explicaciones diferentes. La comunicación de revisión es una conversación de depuración, no un concurso para enviar la respuesta más larga.

El procesamiento de compilación y TestFlight son puntos de control separados

Una compilación cargada no está necesariamente lista para enviar. La referencia de estado de compilación de Apple distingue entre procesamiento, información de cumplimiento faltante y listo para enviar. También distingue los estados de TestFlight Esperando revisión y En revisión beta de la disponibilidad para probadores internos. Las pruebas beta externas pueden requerir la revisión de la app de TestFlight. [5]

Si tu beta está atascada, inspecciona el estado de la compilación antes de buscar un problema en la cola de revisión de App Store. Para Cumplimiento faltante, Apple indica a los desarrolladores que respondan las preguntas de cifrado o proporcionen la documentación pertinente. Algunas compilaciones pueden declarar una exención aplicable a través de su configuración, pero debes responder con precisión en lugar de cambiar la configuración solo para evitar el aviso. [6]

Aprobado no siempre significa disponible de inmediato

El flujo de trabajo de publicación de Apple separa elegir una compilación, establecer disponibilidad, enviar, resolver problemas de revisión y distribución. Dice que una app aprobada puede tardar hasta 24 horas en estar disponible. También eliges si el lanzamiento es manual, automático o por fases. Verifica esas configuraciones antes de describir una versión aprobada como “aún en revisión”. [7]

Para las actualizaciones, un lanzamiento por fases distribuye gradualmente la versión a los usuarios elegibles con actualizaciones automáticas durante siete días. Esa es una elección de implementación, no siete días adicionales de revisión. Si un cliente aún ve una versión anterior, primero confirma el método de lanzamiento y la disponibilidad en lugar de asumir que el revisor ha retenido la aprobación. [8]

Google Play tiene una ventana de revisión diferente

No apliques los tiempos de Apple a Google Play. Google dice que las revisiones de los envíos pueden tardar desde unas horas hasta siete días, y más en casos excepcionales. Su descripción general de publicación también advierte que enviar otro cambio mientras hay cambios en revisión puede hacer que la app retroceda en la cola de revisión. Por lo tanto, las ediciones pequeñas repetidas pueden ir en contra de un lanzamiento predecible. [9]

La descripción general de publicación de Play Console distingue los cambios en revisión de los cambios listos para publicar. Con la publicación gestionada habilitada, la aprobación y la publicación son decisiones separadas. Mira la cola de cambios, no solo si la nueva ficha es visible en un teléfono. Termina el paquete de lanzamiento previsto antes de enviarlo y evita ediciones no relacionadas mientras esperas, a menos que algo realmente necesite corrección.

Un ejemplo práctico: diagnosticar antes de volver a enviar

Imagina una aplicación de seguimiento de hábitos enviada el lunes por la mañana. El martes por la noche, el fundador comienza a reconstruirla porque la aprobación no ha llegado. Antes de hacer eso, verifica tres cosas: si la versión está realmente en cola, si la revisión ha enviado un mensaje y si la cuenta proporcionada puede completar la incorporación. Este es un escenario ilustrativo, no un caso medido de cliente de AsoTheory.

Si la aplicación simplemente está esperando y el acceso funciona, una compilación de reemplazo no ofrece una solución demostrada. Si un revisor informa un fallo de inicio de sesión, corregir el acceso aborda un obstáculo real. Si el estado es Pendiente de lanzamiento del desarrollador, la acción correcta es lanzar, no volver a enviar. El mismo tiempo transcurrido puede requerir tres respuestas completamente diferentes. Por eso diagnosticar el estado viene antes de elegir un remedio.

¿Cuándo deberías contactar a Apple?

Para un retraso inexplicable e inusualmente largo, utiliza la ruta de contacto de revisión de Apple con una línea de tiempo concisa e identificadores de envío. Describe el estado actual, cualquier correspondencia previa y lo que ya has comprobado. No hay un umbral universal de días en la guía citada que garantice una escalada. Evita inventar uno o prometer que un mensaje de soporte hará avanzar tu app.

La revisión acelerada es una solicitud separada. Apple da ejemplos como una corrección de errores crítica o un lanzamiento vinculado a un evento con el que estás directamente asociado. Explica la circunstancia real y el impacto; la impaciencia de marketing ordinaria no es lo mismo. Una solicitud acelerada no debe presentarse como un atajo garantizado. [1]

Planifica el lanzamiento en torno a la incertidumbre

Una nota de lanzamiento interna útil tiene cuatro campos: qué está cambiando, a qué pueden acceder actualmente los clientes, quién está revisando la correspondencia de revisión y qué desencadena el anuncio. Asigna a una persona como responsable del envío. Acuerda un horario de registro en lugar de que todos actualicen la consola toda la tarde. Mantén la evidencia junta, incluidos los mensajes del revisor y la versión exacta enviada. Nada de esto acorta la cola de Apple, pero evita que la incertidumbre se convierta en reconstrucciones innecesarias o decisiones conflictivas.

Si tu lanzamiento añade una nueva suscripción o cambia la incorporación, prepara respuestas de soporte antes de que llegue la aprobación. Asegúrate de que tus enlaces de marketing describan la versión que la gente realmente puede descargar. Evita anunciar que una función está activa solo porque su compilación ha sido aceptada. Para un primer lanzamiento, ten listo un mensaje alternativo en la página de destino. Estas son recomendaciones operativas, no requisitos de la tienda ni promesas sobre la velocidad de revisión: su valor es que tu equipo aún puede actuar con sensatez cuando el cronograma está fuera de su control.

Mantén la preparación de la revisión en una lista de verificación de lanzamiento: acceso funcional, notas claras, flujos de compra probados, activos precisos, correspondencia monitoreada y una configuración de publicación deliberada. Deja margen entre el envío y cualquier fecha de campaña fija. Si el tiempo es esencial, decide de antemano qué sucede si la aprobación llega tarde: pausa el anuncio, mantén disponible la versión actual o comunica una ventana revisada.

Finalmente, distingue la evidencia de las historias. Las largas esperas de otros desarrolladores pueden ser reales, pero no prueban por qué tu app está retrasada. Ni la guía citada de Apple ni la de Google establecen una explicación universal como que las apps generadas por IA causan un retraso. La pregunta útil no es "¿qué rumor explica esto?" sino "¿en qué estado está mi envío y hay alguna acción que realmente pueda tomar?"

Relacionado

Blog · Casos de estudio · Free ASO tools · Productos · Privacidad y términos · AsoTheory