Los fundadores preguntan esto como si fuera un número. No lo es. Apple y Google revisan apps; ninguna promete un plazo; las dos publican una ventana típica que luego se trata como contrato. Yo publico cuatro apps de consumidor en las dos tiendas — Luna, Smart Clip, Routina y Callendar — así que lo que sigue es el calendario contra el que planifico en 2026, no un gráfico de 'tiempo medio de review' copiado de internet.
Los rangos honestos, no una promesa
Son números para planificar. Un binario concreto puede ir más rápido o más lento. Trátalos como colchón, no como SLA.
- Apple, actualización rutinaria de una app ya publicada: a menudo 24–48 horas. Muchas siguen saliendo en menos de un día. Es el caso que uso cuando el cambio es un arreglo o una función pequeña en una cuenta que Apple ya conoce.
- Apple, primera sumisión o un cambio gordo: dos a cinco días es un prior mejor que 'mañana'. Apps infantiles, entitlements nuevos, pagos, Health, y cualquier cosa que parezca un producto nuevo dentro de una ficha vieja se van al extremo largo. Apple dijo en junio de 2026 que el 90% de las sumisiones salían en 48 horas, con una media de 1,5 días sobre un volumen semanal enorme. Esa media incluye nits de metadatos y actualizaciones de binario. No es la fecha de tu launch.
- Google Play, app establecida, update de producción: a menudo horas o un par de días. El texto de Google sigue siendo 'unas horas hasta siete días, más en casos excepcionales'. Las releases de Play que importan las mando días antes, no horas.
- Google Play, primera producción en una cuenta personal nueva: lo que domina no es la review del binario. Hace falta un test cerrado de 14 días con al menos 12 testers, luego una review de acceso a producción (Google dice que suele ser siete días o menos) y después la review de la release. De punta a punta, una cuenta personal nueva son semanas, no un fin de semana.
La página de App Review de Apple sigue diciendo que el 90% de las sumisiones se revisan en menos de 24 horas. Esa frase lleva años en la página. Úsala como estadística de población, no como la fecha que le das a un periodista.
Un lanzamiento a dos stores es tan lento como la tienda más lenta
Si el producto tiene que aparecer en las dos tiendas la misma mañana, no te quedas con la mediana de Apple ni con la de Play. Te quedas con la que termina última, más el rechazo que deberías haber presupuestado.
El calendario práctico que uso:
- Corta el binario cuando el producto está de verdad hecho. No cuando está hecha la landing. La review de la tienda no testa tu web.
- Manda primero a Apple si el cambio es sensible a guidelines. Infantil, teclados, modos en segundo plano, 'suena como una llamada'. Apple es quien discute el producto, no solo la ficha.
- Manda Play con colchón, no con esperanza. Un update rutinario suele ser rápido. El que toca declaraciones de política, audiencia o un permiso nuevo es el que se queda parado.
- Asume un rechazo en una primera versión. Un rechazo es otro ciclo completo de review, no un sello el mismo día. Si el launch tiene fecha externa, eso son dos ciclos de colchón, no uno.
Qué alarga de verdad la cola
No 'el reviewer tuvo un mal día'. Las mismas cuatro cosas, todos los años:
- La app es para niños. Luna es una app de cuentos para dormir, más o menos de dos a nueve años. Categoría Kids, privacidad con forma de COPPA, texto generado. Apple lo lee como review de contenido y seguridad, no como un checksum del binario. Planifica más largo que el update de una app del tiempo.
- La app puede ver lo que escribes. Smart Clip es un teclado de IA y una herramienta de escritura en la hoja de compartir. 'Full Access' en iOS es una conversación de confianza. El texto de privacidad, las afirmaciones de que no se venden datos y un vídeo de demo aburrido importan aquí más que un icono nuevo.
- La app dice ayudar con ansiedad o atención. Routina es una checklist de salida para cerebros con TDAH — cerradura, gas, llaves, registrado. No es un dispositivo médico. La ficha tiene que quedarse en ese carril. El lenguaje cercado a salud es cómo un update de 24 horas se convierte en una semana.
- La app hace algo que el sistema ya hace, más alto. Callendar dispara una alarma de reunión que se comporta como una llamada, a través de Silencio y Focus. Cualquier cosa que parezca pelearse con No Molestar recibe una mirada humana.
La elección de framework casi nunca es por qué la review es lenta. Nativo vs Flutter vs React Native cambia el binario, no al reviewer.
Cómo se vio en las cuatro apps
No voy a inventar horas por build. Los tiempos de review no son una clasificación, y un binario suertudo te enseña la lección equivocada. El patrón al publicar estas cuatro:
- Luna — lunastorytelling.kids. La primera ficha infantil fue la lenta. Los updates posteriores del motor de cuentos y de localización se han comportado como updates normales, mientras la edad, la etiqueta de privacidad y la historia del contenido generado coincidan con lo que Apple ya aprobó.
- Smart Clip — smart-clip-app.com. Teclado + escritura en 30 idiomas. La historia de permisos y privacidad es la review. El cambio de código, normalmente, no.
- Routina — routina-app.com. Checklist, hápticos, fotos en el dispositivo. Los updates que solo cambian copy y toques pasan como una utilidad. Cualquier cosa que suene a tratamiento, no.
- Callendar — callendarmeetings.com. Alarmas de calendario que suenan. La primera versión tuvo que mostrar la alarma en un dispositivo en las notas de review. Después, los arreglos pequeños de sync han sido aburridos.
Play, en las mismas cuatro, ha sido más rápido en updates rutinarios de producción y más lento la vez que una ficha o un cuestionario estaba desfasado. El binario estaba bien. El formulario no.
Cómo planificar una fecha que puedas cumplir
- No anuncies el día de tienda hasta que el primer binario esté en review. Las landings pueden salir. La prensa no.
- Ten un segundo binario más pequeño listo. Si Apple rechaza un texto, quieres reenviar la misma tarde, no un sprint nuevo.
- Escribe las notas de review como un guion de demo. 'Toca esto, luego esto, verás X.' Los reviewers no son tus usuarios.
- Haz coincidir las etiquetas de privacidad con el build. Un update de teclado con la nutrition label del año pasado es cómo te compras una semana.
- Si la cuenta es nueva en Play, arranca el test cerrado de 12 testers el día que tengas un build sin crashes. Ese reloj de 14 días no espera a que tu web esté lista.
La pregunta que hay que hacerle a un proveedor
No '¿sabes cuánto tarda la review?'. Todo el mundo dirá 24 horas.
Pregunta: '¿cuándo enviáis respecto a la fecha que le dijimos al board, y qué pasa si Apple dice que no una vez?' La respuesta te dice si han publicado una app de tienda en 2026 o están citando un post de 2022.
Si quieres el mismo sprint de dos semanas que usamos para meter estas cuatro en dispositivos — incluido el packaging de tienda, no solo las pantallas — ese es el trabajo. La construcción es la parte corta. La cola va al reloj de Apple y de Google, y siempre fue así.