Tiempo de revisión en la App Store: 64 decisiones reales, mediana de 73 horas

En resumen: recopilé todos los correos de decisión de App Review que ha recibido mi cuenta de desarrollador: 64 decisiones sobre 21 apps de iPhone, del 10 de septiembre al 12 de octubre de 2026, cada una con la marca de tiempo "Submitted" de la propia Apple y la hora a la que llegó la decisión. La espera mediana fue de 73 horas. La página de Apple dice que revisa "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (al menos el 50% de los envíos en menos de 24 horas y el 90% en menos de 48). Las mías: 19% en menos de 24 horas, 27% en menos de 48. Las actualizaciones de apps ya publicadas tardaron una mediana de 64 horas, las compras dentro de la app enviadas por separado tardaron 12, y 0 de 21 apps nuevas se aprobaron en su primer envío.

Respuesta corta para quien llega desde un buscador. Si planeas un lanzamiento en 2026, calcula 3 días por ronda de revisión para una actualización, de 2 a 5 días para la aprobación de una app totalmente nueva y al menos una ronda extra para una app nueva en una cuenta nueva, porque la primera suele volver con una pregunta. Una revisión que se queda parada una semana no es una aprobación lenta. En mis datos, todas las esperas de más de 5,1 días salvo una terminaron en un rechazo por spam de la guideline 4.3.

Si todavía estás en la fase de "cuánto me va a costar esto", la calculadora gratuita del coste de una app de iPhone convierte funcionalidades en horas y dólares; este artículo trata de la parte que ninguna calculadora muestra, el tiempo de calendario entre "Submit" y "Ready for Distribution". Construyo estas apps desde un PC con Windows y sin Mac (aquí está el pipeline), así que cada envío de los que siguen salió de un job de CI o de la web de App Store Connect, nunca de Xcode.

¿Cuánto tarda la revisión de la App Store en 2026?

Aquí están las cifras, desglosadas tal y como te las vas a encontrar. La "espera" es el tiempo desde la línea "Submitted" del correo de Apple hasta el momento en que llegó el correo con la decisión, así que incluye la cola, no solo los minutos que un revisor pasó con la app.

Qué envías	Decisiones	Espera mediana	Más rápida	Más lenta	Aprobadas
Solo compras dentro de la app	5	12,2 h	11,7 h	13,4 h	5 de 5
Actualización de una app publicada	16	64,4 h	6,3 h	203,6 h	11 de 16
App nueva (rondas normales)	21	51,2 h	3,1 h	120,5 h	8 de 21
App nueva (las dos tandas de spam 4.3)	22	187,8 h	167,7 h	223,3 h	0 de 22
Todas	64	73,1 h	3,1 h	223,3 h	24 de 64

Hay dos cosas que saltan a la vista. Los rechazos y las preguntas sobre apps nuevas vuelven rápido (los 13 normales tuvieron una mediana de 27,8 horas), porque el revisor se detiene en el primer problema. Las aprobaciones tardan más: las 8 aprobaciones de primeras versiones tuvieron una mediana de 69,9 horas y ninguna llegó en menos de 48. Así que una respuesta rápida es, estadísticamente, una mala noticia.

El experimento: un par de marcas de tiempo por correo

App Store Connect no te da un historial de duraciones de revisión. Tu bandeja de entrada sí. Todas las decisiones que envía Apple tienen la misma forma: un asunto que dice "Review of your App (iOS) submission is complete." o "There's an issue with your App (iOS) submission.", y una línea en el cuerpo como Submitted: Oct 08, 2026 at 03:48 PM Pacific Daylight Time. La hora de envío del propio correo es la hora de la decisión. Ese es todo el conjunto de datos.

Busqué en Gmail con una sola consulta con operadores de búsqueda, from:no_reply@email.apple.com newer_than:60d, el 17 de octubre de 2026. Devolvió 69 hilos; 64 son decisiones (los otros cinco son la bienvenida a App Store Connect, la aprobación del acceso a la API, dos avisos de "Welcome to the App Store" y un "Thank you for submitting"). La cuenta se abrió el 10 de septiembre, así que esto es el historial completo, no una muestra. Después, el análisis:

# media/deepdive/review-time/analyze.py (trimmed)
PT = timezone(timedelta(hours=-7))  # Pacific Daylight Time, as printed in Apple's emails

def sub_dt(s):  # "Oct 08 03:48 PM" from the email body
    return datetime.strptime("2026 " + s, "%Y %b %d %I:%M %p").replace(tzinfo=PT)

for e, app, out, sub, by, kind in ROWS:
    s = sub_dt(sub); d = utc(e)          # e = the email's sent time, UTC
    h = (d - s).total_seconds() / 3600   # hours from Submitted to decision
    recs.append(dict(app=app, outcome=out, kind=kind, hours=round(h, 2), ...))

Cada fila está etiquetada además según lo que contenía el envío: la primera versión de una app nueva, una actualización o compras dentro de la app por sí solas. Lo saqué de los propios registros de cada app (el historial de commits de los repos y mis notas) y comprobé la tanda ambigua contra el cuerpo del correo, que enumera los elementos: el envío de Chain de la noche del 8 de octubre dice In-App Purchases (6) y ninguna versión de la app. Los motivos de rechazo no aparecen en los correos (el cuerpo solo dice "We noticed an issue"), así que salieron de los textos del Resolution Center que había guardado y de las respuestas que envié.

Lo que este método no puede ver: los envíos que cancelé antes de una decisión (sin correo, sin fila) y el momento exacto en que un revisor abrió la app. Si quieres el "tiempo en revisión" en lugar del "tiempo de espera", la API de App Store Connect expone el estado de la versión, pero no su historial, así que tendrías que consultarla periódicamente por tu cuenta.

Las 24 horas de Apple frente a las mías

Apple elige bien sus palabras: dice que revisa la mitad de los envíos en menos de 24 horas. Eso puede ser cierto y aun así no coincidir con lo que tú percibes, por tres motivos que aparecen en mis datos.

Primero, el reloj arranca en una cola. Mis aprobaciones se agrupan casi exactamente en el mismo tiempo transcurrido. Siete de las 16 actualizaciones llegaron entre 63,5 y 64,5 horas, porque se enviaron juntas el sábado 26 de septiembre por la mañana y se resolvieron juntas, en 32 minutos, a última hora de la noche del lunes, hora del Pacífico. Durara lo que durara la revisión en sí, la espera la marcó el momento en que la cola llegó a ellas.

Segundo, Apple no parece tomar decisiones nuevas los sábados, al menos no sobre las mías. De 64 decisiones, en hora del Pacífico: lunes 35, viernes 10, jueves 7, miércoles 5, domingo 4, martes 3, sábado 0. El montón del lunes está inflado por las dos tandas de spam (22 decisiones), pero incluso sin ellas no llegó nada en sábado. Así que sí, App Review trabaja los domingos (dos de las cuatro decisiones de domingo fueron aprobaciones), pero un envío del sábado por la mañana aun así esperó hasta el lunes por la noche.

Tercero, la cola lenta no es aleatoria. Sin las dos tandas 4.3, mis cifras se parecen mucho más a las de Apple: 29% en menos de 24 horas, 40% en menos de 48. Los 22 rechazos por spam tardaron de 7 a 9,3 días cada uno. Las esperas largas eran una señal, no mala suerte.

El carril rápido son las compras dentro de la app. Cinco envíos solo de IAP (temas y packs nuevos para cinco apps publicadas, enviados por la API a última hora de la noche del jueves 8 de octubre) volvieron todos aprobados entre 11,7 y 13,4 horas después, con 95 minutos de diferencia entre ellos. Si necesitas lanzar un nuevo precio o un pack rápidamente, envíalo por separado y no toques el binario.

Apps nuevas: 0 de 21 aprobadas al primer intento

A las 21 apps les devolvieron el primer envío. Suena alarmante hasta que lees los motivos. Diez de los 21 correos de primera ronda fueron de la guideline 2.1 "Information Needed" (los otros 11 fueron la tanda de spam que verás más abajo), las preguntas rutinarias que recibe una cuenta de desarrollador nueva: enviar una grabación de pantalla de la app en un dispositivo, explicar las funciones principales, decir si necesita inicio de sesión, enumerar los servicios externos. Las guidelines de Apple piden esto de antemano; los revisores lo vuelven a pedir de todos modos cuando la cuenta es nueva.

Lo que funcionó fue dejar de tratar las notas de revisión como un trámite. Ahora cada app incluye un Store/review-notes.md que el pipeline sube a los detalles de revisión de App Store Connect, escrito como un recorrido que un revisor puede seguir en menos de un minuto, incluido cómo llegar a cada pantalla de pago:

# chain/Store/review-notes.md (trimmed)
No account, login or network connection is required.

IN-APP PURCHASES (StoreKit 2, all optional, Restore in Settings):
- Chain Unlimited (existing non-consumable): add three habits, tap New habit again; ...
- Streak Repair, $0.99 consumable: when a chain of 2+ days breaks, Today shows a
  "chain broke" banner and the rescue sheet opens. ... To see it on a fresh install:
  add a habit, open Week, tick the two days before yesterday, leave yesterday empty,
  then relaunch.

PRIVACY: no data is collected. No accounts, analytics, ads or third-party SDKs.

Tras la primera ronda de 2.1, Chain, Ironbook y Quiver se reenviaron el 22 de septiembre a las 4:21 AM, hora del Pacífico, con respuestas y una grabación de pantalla, y las tres se aprobaron entre 51 y 67 horas después. De las 8 apps que llegaron a la tienda, el tiempo mediano desde el primerísimo envío hasta la primera aprobación fue de 4,4 días (rango de 3,75 a 7,2). Esa es la cifra honesta para un plan de lanzamiento de una app nueva en una cuenta nueva: no 24 horas, sino algo más cercano a una semana laboral.

Vale la pena conocer los demás motivos de primera ronda, porque cada uno se evita con poco esfuerzo:

• Privacidad 5.1.1, dos veces, la misma app. A Minder, un temporizador de concentración cuyos ojos de dibujo animado pueden seguir tu cara (la animación de los ojos está en este artículo sobre SwiftUI), le preguntaron exactamente qué datos faciales recoge, guarda y comparte. La respuesta (una posición x/y del framework Vision de Apple, que funciona en el dispositivo, y que nunca se almacena) tenía que estar en la política de privacidad, no solo en la respuesta. Una semana después la rechazaron otra vez porque la propia URL de la política de privacidad había dejado de cargar. Arreglé el alojamiento, reenvié seis minutos después del correo y se aprobó 24,8 horas más tarde.
• 1.4.1, las afirmaciones de salud necesitan fuentes. Race Fuel da objetivos de carbohidratos, líquidos y sodio para carreras de resistencia. La guideline 1.4.1 exige que las cifras cercanas a lo médico estén respaldadas por citas. La solución fue una pantalla de fuentes con siete artículos científicos enlazados por DOI y un enlace bajo cada cifra.

Guideline 4.3: una semana de silencio y luego 11 rechazos en 30 segundos

Once de mis apps (un registro de mantenimiento del coche, un temporizador de estacionamiento, un inventario del hogar, un registro de precios del supermercado, un control de medicación para mascotas, un cuadro de tareas domésticas, un registro de propinas, una calculadora de notas, un registro de escalada en bloque, una calculadora de ritmo de carrera y una calculadora de hora límite de cafeína) se enviaron el 26 de septiembre. Pasaron de 8,7 a 9,3 días en la cola. Después, el lunes 5 de octubre, llegaron los 11 correos de rechazo entre las 5:29:32 PM y las 5:30:02 PM, hora del Este. El mismo texto para todas las apps: guideline 4.3 Spam más 4.2.6, apps creadas a partir de una plantilla o de un servicio de generación de apps, con nueve preguntas que responder. El Resolution Center mostraba todos los mensajes con la hora 5:29 PM.

El texto del rechazo era explícito sobre qué hacer a continuación: si crees que la app ya cumple, no la reenvíes, responde al mensaje y contesta las nueve preguntas. Respondí a cada uno (sin beta pública, probadas mediante ejecuciones automáticas en el Simulator; una clase de compra de StoreKit y un driver de pruebas compartidos, declarados), presenté apelaciones ante el App Review Board para las 11, y además reenvié las 11 esa misma tarde. Los reenvíos fueron el error. Siete días después, el lunes 12 de octubre, llegaron 11 rechazos más en 27 segundos, cada uno 7,0 días después de su reenvío.

Lo que dicen los datos sobre la 4.3, si estás planeando tu propio lanzamiento:

• La espera te da la pista. En mis datos, todas las revisiones de más de 5,1 días salvo una fueron rechazos 4.3. La excepción fue Clear the Strait 1.1.1, que reenvié junto con una larga explicación escrita de cómo funciona el juego después de que el revisor la pidiera; tardó 8,5 días y se aprobó.
• Se decide por desarrollador, no por app. Las dos tandas llegaron en menos de 30 segundos. Fuera lo que fuera esa revisión, no fueron 11 sesiones separadas con 11 apps.
• No reenvíes sin cambios. El propio correo de Apple decía que un reenvío sin cambios sustanciales se rechazaría de nuevo. Así fue, con un reloj de siete días, lo que costó una semana por ronda.

Antes medí cuánto código Swift comparten realmente esas apps. El solapamiento mediano con el resto de la cuenta fue del 34,5%, y las dos apps más parecidas de la cuenta (un diario de golf y un diario de tenis) están publicadas. La similitud del código por sí sola no explicaba a quién marcaron; las cifras están en el artículo sobre el coste de una app de iPhone. Mi interpretación, presentada como tal: 11 utilidades de un solo propósito desde una cuenta nueva, enviadas la misma mañana, parecen una fábrica de apps vistas desde la cola, por muy distintas que sean las pantallas. Si tienes varias ideas de apps pequeñas, lanza una, deja que acumule reseñas y actualizaciones y espacia las demás, o reúnelas en una sola app con compras dentro de la app, que es exactamente lo que sugiere la guideline 4.3(a).

Todo el calendario en una imagen

Visto como calendario, el patrón es evidente. Las dos primeras semanas son barras rojas cortas (preguntas rápidas de la 2.1) seguidas de barras verdes de dos a cinco días. A partir del 26 de septiembre la cuenta se divide en dos: las apps que ya estaban publicadas sacan sus actualizaciones en unas 64 horas, mientras que las 11 utilidades nuevas se quedan en dos largas barras rojas que terminan cada vez en la misma ventana de 30 segundos.

Después de la aprobación: publicada en minutos

El correo dice que "puede tardar hasta 24 horas" en aparecer un elemento aprobado. En mis 8 apps publicadas, la marca de tiempo de publicación llegó mucho antes. La leí de la propia iTunes Search API de Apple, que devuelve un currentVersionReleaseDate para cada app que un desarrollador tiene en la tienda:

# every app on the account, with the release time of its current version
curl -s "https://itunes.apple.com/lookup?id=6810582483&entity=software&country=us"

Comparada con los correos de aprobación, esa hora de publicación llegó entre 0,7 y 7,5 minutos después de la aprobación, con una mediana de 2,5 minutos, en las 8 apps. Si tu fecha de lanzamiento importa (prensa, una campaña de anuncios, un hueco en Product Hunt), elige una publicación manual para que una aprobación a las 2 AM no salga antes de tu anuncio.

Mientras esperas, querrás ver el estado sin abrir App Store Connect. Esta es la comprobación de estado que lleva cada uno de los repos de mis apps; le pide a la API de App Store Connect las últimas cinco versiones y builds:

# chain/Store/asc.py
def status():
    app = find_app()
    if not app:
        print("no app record for", BUNDLE_ID)
        return
    print(f"{app['attributes']['name']}  ({BUNDLE_ID})  id={app['id']}")
    versions = call(
        "GET", f"/v1/apps/{app['id']}/appStoreVersions", params={"limit": 5}
    )
    for v in (versions or {}).get("data", []):
        a = v["attributes"]
        print(f"  version {a.get('versionString')}: {a.get('appStoreState')}")

El envío en sí es una sola llamada a fastlane al final de un job de CI, usando upload_to_app_store. Las tres respuestas de submission_information importan más de lo que parece: son las preguntas sobre cumplimiento de exportación, identificador de publicidad y derechos de contenido, y responderlas en código significa que un envío nunca se queda atascado esperando a que alguien rellene un formulario.

# chain/fastlane/Fastfile, lane :release (trimmed)
upload_to_app_store(
  api_key: asc_key,
  app_identifier: APP_IDENTIFIER,
  ipa: "build/Chain.ipa",
  # Submit, rather than leaving it sitting in Connect for a human to press
  # the button on. This is the last step and it is the irreversible one.
  submit_for_review: true,
  force: true,
  precheck_include_in_app_purchases: false,
  submission_information: {
    add_id_info_uses_idfa: false,
    export_compliance_uses_encryption: false,
    content_rights_contains_third_party_content: false
  }
)

¿La revisión de la App Store funciona los fines de semana?

En parte. Cuatro de mis 64 decisiones llegaron en domingo, hora del Pacífico: la primera aprobación de Pocket Beings a las 4:05 PM del 20 de septiembre, y tres la noche del 11 de octubre (dos actualizaciones 1.2 devueltas y Chain 1.2 aprobada a las 10:42 PM). Ninguna llegó en sábado. Los 19 envíos que hice el sábado 26 de septiembre se resolvieron todos el lunes por la noche o más tarde, y las cinco actualizaciones que envié el jueves 8 de octubre volvieron el domingo por la noche y el lunes a primera hora. Si puedes elegir, envía de lunes a miércoles; todo lo que envíes el jueves o después, cuenta con que se resuelva después del fin de semana.

Lo que yo haría en tu proyecto

1. Planifica en rondas, no en días. Una ronda son unos 3 días para una actualización y de 2 a 5 para una app nueva. Una app nueva en una cuenta nueva necesita dos rondas: calcula una semana laboral desde el primer envío hasta la aprobación.
2. Escribe las notas de revisión como un guion de pruebas. Inicio de sesión (o "sin inicio de sesión"), dónde está cada pantalla de pago, cómo provocar los casos límite, qué datos recoges. Adjunta una grabación de pantalla al primer envío para que la 2.1 no tenga nada que preguntar.
3. Comprueba que la URL de tu política de privacidad carga antes de cada envío. Un enlace roto me costó una ronda entera.
4. Envía las compras dentro de la app por separado cuando la velocidad importe. 12 horas, 5 de 5 aprobadas.
5. Trata una revisión de más de 5 días como una advertencia. Prepara las respuestas a las nueve preguntas de la 4.3 antes de necesitarlas.
6. Cuando Apple diga que respondas, no reenvíes. Un reenvío sin cambios me valió otro rechazo idéntico, siete días después, a la hora exacta.
7. Corrige y reenvía rápido cuando el problema sea concreto. El enlace roto de la privacidad de Minder: reenviada en 6 minutos, aprobada en 25 horas.
8. ¿Lo necesitas antes? Apple tiene una solicitud de revisión acelerada para correcciones de errores críticos y eventos con fecha. No la he usado, así que no tengo cifras sobre ella.
9. Mide la tuya. Ejecuta la misma consulta de Gmail en tu cuenta. Diez minutos te dan tu calendario real de revisiones, que vale más que cualquier promedio, incluido este.

Los datos y cómo volver a obtenerlos

Todo está en una sola carpeta: emails.py (las 64 filas transcritas de los correos, con la consulta de Gmail y la hora de extracción), analyze.py (medianas, grupos, tandas, retraso entre aprobación y publicación), summary.json (cada cifra calculada de este artículo) y make_charts.py (los gráficos). Extraído el 17 de octubre de 2026 hacia las 10:15 PM, hora del Este; la consulta a iTunes se hizo hacia las 10:20 PM. La afirmación de Apple se leyó en developer.apple.com/distribute/app-review esa misma noche, y el flujo de envío está descrito en la página de ayuda Submit for review de Apple. Una cuenta de desarrollador, 21 apps, cinco semanas: una muestra pequeña, pero completa, y el único tipo de datos de tiempos de revisión que puedes verificar de verdad.

Si desarrollas en Windows y quieres el mismo pipeline (builds en la nube, firma, capturas, envío con fastlane, la plantilla de notas de revisión) montado en tu propio repo, eso es el No-Mac iOS Pipeline, $299: tu primera build de TestFlight desde un PC con Windows en 5 días hábiles. Si prefieres encargar la app entera, tienes desarrollos a precio cerrado en /build/.