Respuesta rápida
No hay un solo tiempo de revisión de Google Play en 2026. Las versiones de pruebas internas suelen estar disponibles en minutos, tu primera versión de prueba cerrada (closed testing) pasa por una revisión manual que puede tardar hasta 7 días, la revisión de acceso a producción suele tardar 7 días o menos según el propio texto de Google, y las revisiones estándar de app o actualización suelen ser rápidas, pero pueden tardar hasta 7 días o más en casos excepcionales. La prueba cerrada obligatoria de 14 días no es una cola de revisión: es una ventana de prueba que operas tú. De punta a punta, una cuenta personal de desarrollador nueva suele necesitar de 3 a 5+ semanas desde la creación de la cuenta hasta la app en vivo. PrimeTestLab gestiona la única etapa que controlas por completo, la prueba cerrada, para que los relojes de revisión de Google sean la única espera.
Cada etapa de un lanzamiento en Google Play tiene su propio reloj, y mezclarlos es cómo un plan de tres semanas se convierte en silencio en uno de seis. Este post recorre el pipeline de 2026 etapa por etapa: los números que Google sí declara, las etapas sin plazo prometido, la ventana que es trabajo tuyo y no de Google, y la aritmética de una estimación realista del primer envío a app en vivo. Actualizado al 11 de julio de 2026; donde el número importa, usamos el texto de Google y no un rumor de foro. Para la secuencia completa de lanzamiento alrededor de estos relojes, ve nuestra guía de requisitos de publicación en Google Play.
Léelo como matemática de planificación
Lee cada número aquí como matemática de planificación, no como promesa. Los plazos que declara Google son techos y típicos: "suele tardar 7 días o menos" significa que la mayoría termina antes y unos pocos tardan más. Ninguna etapa tiene una fecha de finalización garantizada, y nada en este post cambia eso.
Qué cubre este post
¿Cuánto tarda la revisión de Google Play en 2026?
Entre minutos y alrededor de una semana por revisión, según cuál estés esperando. Las versiones de pruebas internas suelen estar disponibles en minutos. Tu primera versión de prueba cerrada puede tardar hasta 7 días de revisión manual. La revisión de acceso a producción suele tardar 7 días o menos, según el texto de Google. Y las revisiones estándar de versión o actualización suelen ser rápidas, pero sin plazo prometido. Los famosos 14 días se sitúan entre esas revisiones y no son una revisión en absoluto.
"Tiempo de revisión de Google Play" son en realidad cinco relojes distintos, y cada uno se comporta de forma distinta. Aquí va el pipeline completo de 2026 en una tabla, con quién sostiene cada reloj y lo que Google declara de verdad:
-
01
Versión de pruebas internas Minutos, en general
Los builds suelen estar disponibles para testers internos en minutos, aunque la primera versión puede revisarse y el enlace de la prueba puede tardar unas horas en funcionar tras la primera publicación.
-
02
Primera versión de prueba cerrada Hasta 7 días
Una revisión manual de Google se interpone entre tú y tus testers. Esos días no cuentan para el requisito de 14 días.
-
03
La prueba cerrada de 14 días 14 días, tu reloj
No es una revisión. Es una ventana de prueba que operas: los testers mantienen la participación aceptada y usan la app de verdad. No puedes acortarla; solo puedes evitar reiniciarla.
-
04
Revisión de acceso a producción Suele ser 7 días o menos
Texto de Google. Solicitas el acceso con un cuestionario de tres secciones tras la ventana; la decisión se envía por correo al titular de la cuenta.
-
05
Versión final + actualizaciones Sin plazo fijo
Las revisiones estándar suelen ser rápidas, pero algunas tardan hasta 7 días o más en casos excepcionales. Nunca envíes una versión con fecha límite al último minuto.
Fíjate en el patrón: Google sostiene cuatro de los cinco relojes, y el único reloj que tienes tú, la prueba de 14 días, es también el que más lanzamientos tropiezan. El comportamiento de revisión también depende del canal de pruebas (segmento de pruebas) al que publiques; si aún eliges entre canales, nuestro comparativo de pruebas internas, cerradas y abiertas mapea los tres antes de que te comprometas.
Revisión de la primera app: ¿qué debes esperar?
Tu primera app enfrenta más momentos de revisión que cualquier app que publiques después. Primero va la verificación de identidad y tarda unos días. Luego tu primera versión de prueba cerrada pasa por una revisión manual que puede tardar hasta 7 días. Solo después de la prueba de 14 días llegas a la revisión de acceso a producción. En un primer lanzamiento, planifica el extremo lento de cada rango.
Un primer envío no se revisa una sola vez; atraviesa una cadena de controles y cada uno tiene su propio reloj. Antes de que algo se publique, Google verifica tu identidad, lo que suele tardar unos días. Tu primer upload a un canal cerrado espera luego la revisión manual de la primera versión. Tras la ventana de prueba, la solicitud de acceso a producción y la revisión final de la versión siguen entre tú y la tienda. Ninguno de estos pasos es opcional para una cuenta personal nueva, y ninguno se solapa con el que viene después.
La consecuencia práctica: en un primer lanzamiento, el tiempo de revisión se pierde sobre todo en los bordes, antes de que empiece la prueba y después de que termina. Los desarrolladores que solo planifican "los 14 días" descubren que el calendario real se acerca al doble. La buena noticia es que las etapas alrededor de las revisiones pueden solaparse: puedes terminar la ficha de la tienda, las declaraciones y las capturas mientras corre una revisión, y Google anima a iniciar la verificación de identidad de inmediato.
Consejo pro
Arranca la verificación de identidad el día uno y sube tu primer build de prueba cerrada en cuanto esté estable, aunque la ficha esté incompleta. Los días de revisión de la primera versión antes de que pueda empezar la prueba son la línea que más se olvida en la matemática del lanzamiento, y no cuestan nada si corren mientras pulís todo lo demás.
¿Cuánto tardan las revisiones del canal de prueba cerrada?
Tu primera versión de prueba cerrada pasa por una revisión manual de Google que puede tardar hasta 7 días. Los builds posteriores en el mismo canal siguen el flujo normal de revisión de Google, sin plazo prometido. Lo crítico: los días de revisión de la primera versión no cuentan para el requisito de 14 días. Ese reloj arranca solo cuando la versión se aprueba en el canal cerrado y tus testers aceptan participar de verdad.
La prueba cerrada es donde la mayoría de los lanzamientos de 2026 gastan su calendario, porque las cuentas personales de desarrollador nuevas deben ejecutar una prueba cerrada con al menos 12 testers que hayan aceptado participar durante 14 días de forma continua antes de poder solicitar acceso a producción. Si quieres el trasfondo de ese requisito, incluido cómo el mínimo bajó de 20 a 12, ve nuestro post sobre el cambio de política de Google del 11 de diciembre de 2024. Este post se centra en una pregunta más estrecha: cuánto tardan las revisiones alrededor de esa prueba.
La trampa es la primera versión. Las pruebas internas acostumbran a los desarrolladores a ver builds en minutos; la primera versión en un canal cerrado se comporta distinto y se queda en una revisión manual que puede llegar a 7 días. Nada va mal con tu app mientras espera ahí. Pero si programaste a tus testers para "mañana", ahora esperan a Google contigo, y tu ventana de 14 días aún no abrió. Los relojes se alternan así:
Hasta 7 días de revisión manual antes de que los testers puedan unirse. No cuenta para los 14.
Arranca cuando la versión se aprueba y tus testers aceptan participar. Tuyo de operar, tuyo de proteger.
Suele ser 7 días o menos después de que solicitas, según el texto de Google.
Los builds actualizados que envías al canal durante la prueba pasan por el flujo normal de revisión de Google. Google no publica un plazo fijo para ellos, así que trata cada build a mitad de prueba como "a menudo rápido, no instantáneo" y nunca planifiques un ciclo de arreglar y verificar el mismo día alrededor de uno.
La ventana de prueba de 14 días no es una cola de revisión
Durante los 14 días no se revisa nada. La ventana es un requisito de prueba que operas tú: tus testers mantienen la participación aceptada y usan la app de verdad durante 14 días de forma continua. Los revisores de Google vuelven a la escena solo cuando solicitas acceso a producción después. Esperar en silencio no avanza nada; mantener a los testers activos sí.
Esa distinción cambia cómo gastas esas dos semanas. Una cola de revisión premia la paciencia: envías, esperas, alguien decide. La ventana de 14 días premia la operación: cada día tu app necesita testers con participación aceptada y activos, y el requisito se mide de forma continua. Si bajas del conteo requerido a mitad de ventana, se rompe la racha continua; la espera puede empezar de cero con una cohorte nueva. Ningún revisor te avisará de que esto pasa, porque aún no hay revisor mirando.
También significa que la ventana no se puede acelerar, negociar ni acortar por la calidad de la app. Una app impecable debe los mismos 14 días que una tosca. El único rendimiento que controlas es no perder días: reclutar testers que se queden, reponer bajas de inmediato y no confundir el conteo de participación del Console con el uso diario real. Cómo se cuentan los 14 días, qué reinicia el reloj de verdad y qué pasa cuando un tester deja de participar el día 9 es un tema aparte; nuestro explicador de los 14 días consecutivos cubre la mecánica del reloj a fondo.
La ventana solo se abre cuando tus testers han aceptado participar de verdad. Reclutar 12 desconocidos es la parte más lenta e impredecible de todo el cronograma, y es la única con atajo: el roster gestionado de PrimeTestLab suele aceptar participar en 4-6 horas tras el pedido, para que tus 14 días empiecen hoy y no después de semanas de reclutamiento. Mira cómo funciona el servicio de 12 testers →
Revisión de acceso a producción: unos 7 días o menos
Esta es la revisión a la que Google le pone un número. Cuando tu prueba cerrada cumple los requisitos, solicitas acceso a producción con un cuestionario de tres secciones, y Google revisa la solicitud en un plazo que suele ser de 7 días o menos, aunque en ocasiones puede tardar más. La decisión se envía por correo al titular de la cuenta.
El propio texto de Google, de la página de ayuda de Play Console que define el requisito de prueba, vale la pena leerlo tal como está escrito:
"usually takes 7 days or less, but may occasionally take longer."
Ayuda de Google Play Console, requisitos de prueba de apps para cuentas personales de desarrollador nuevas (respuesta 14151465), sobre la revisión de acceso a producciónLo que se revisa es más amplio de lo que la mayoría de solicitantes espera. Google mira la prueba cerrada en sí, es decir la actividad de los testers y no solo el conteo de quienes aceptaron participar, tu app y tus respuestas escritas sobre preparación para producción. Llegar a 12 testers con participación aceptada es necesario, no suficiente: ha habido rechazos cuando el engagement era demasiado bajo, y las respuestas vagas del cuestionario son un motivo frecuente de rechazo. Las tres secciones premian lo concreto, exactamente lo que recorre pregunta a pregunta nuestro post de respuestas del cuestionario de acceso a producción.
Mientras corre la revisión, tres hábitos te sacan de líos: mantén a tus testers con participación aceptada hasta tener la respuesta de Google en la mano, vigila la bandeja del titular de la cuenta incluido el spam porque ahí llega la decisión, y resiste la tentación de cambiar la versión en revisión salvo que algo esté de verdad roto. La solicitud es una foto de una prueba terminada y estable; mantenla pareciendo eso.
¿Cuánto tardan las revisiones de actualizaciones de la app?
Google no promete un tiempo fijo de revisión para actualizaciones. Las revisiones estándar suelen ser rápidas, pero algunas tardan hasta 7 días o más en casos excepcionales. Las actualizaciones de una app que ya tiene acceso a producción no necesitan una prueba cerrada nueva de 12 testers; solo pasan por la revisión normal.
Dos escenarios de actualización se confunden a menudo, y tienen relojes distintos:
Actualizaciones después del acceso a producción. El requisito de prueba se limpia una vez por app, así que una actualización rutinaria de una app en vivo nunca vuelve a disparar la prueba de 14 días. Sí pasa por la revisión estándar de versión de Google, la que no promete plazo. En la práctica eso convierte el timing de updates en una pregunta de planificación más que de política: si una versión importa por una fecha, un empujón de marketing o un arreglo con usuarios esperando, envíala con días de anticipación y no con horas, porque "a menudo rápido" no es "siempre rápido".
Actualizaciones durante la prueba cerrada. Empujar un build mejorado a mitad de prueba es normal, recomendable y seguro para tu calendario: actualizar tu app durante la prueba cerrada no reinicia el reloj de 14 días. El build nuevo igual pasa una revisión normal antes de que los testers lo reciban, así que un update a mitad de prueba pausa un rato tu bucle de feedback, pero nunca tu ventana.
Regla práctica para 2026
Regla práctica para 2026: trata cada revisión estándar como un evento de 1 a 7 días al planificar, y llévate la grata sorpresa cuando se despeje en horas. Los desarrolladores que se queman son los que planificaron alrededor del mejor caso.
Qué ralentiza una revisión (y qué no puedes acelerar)
La mayoría de las revisiones lentas se ralentizan por el envío, no por la cola. Declaraciones incompletas, un login que el revisor no puede pasar, permisos sensibles o una historia de prueba débil suman tiempo o fuerzan un segundo pase. La palanca que no existe: pagar o pedirle a Google que se apresure. No hay un camino documentado de expedición para revisiones estándar.
No puedes ver dentro de la cola de revisión de Google, pero controlas la mayor parte de lo que hace que un envío salga lento o rebote para un ciclo repetido:
Seguridad de datos, clasificación de contenido, anuncios, público objetivo: una declaración que falta o contradice tu app significa reenviar y volver a esperar la revisión.
Si tu app necesita una cuenta, da credenciales demo que funcionen en la sección de acceso a la app. Un revisor que no supera tu pantalla de inicio de sesión no puede terminar de revisar.
Peticiones como ubicación, datos de salud o funcionalidad VPN suelen disparar una revisión más profunda y manual. Pide solo lo que la app demuestra usar.
Un engagement bajo de testers puede cerrar la revisión de producción con un "se requieren más pruebas", lo que reinicia tu ventana. La revisión no fue lenta; la prueba fue delgada. Por qué se rechaza la prueba cerrada desglosa los patrones.
Rebotar una y otra vez por la revisión puede ralentizarte la cola y añadir fricción a envíos futuros. Un pase limpio gana a tres esperanzados.
Declaraciones completas, acceso de revisor que funciona, uso honesto de permisos e historia de prueba con actividad real detrás. Los envíos aburridos se revisan más rápido.
Y la parte que no controlas: Google no documenta un carril de pago rápido, ni una solicitud de expedición, ni un canal de soporte que mueva una revisión estándar hacia arriba en la cola. Quien prometa acelerar el lado de Google del proceso promete algo que Google no vende. Tu apalancamiento vive por completo en la preparación, por eso los lanzamientos más rápidos son los que nunca ven un segundo ciclo de revisión.
¿Tu app está atascada en revisión? Cuándo actuar
Dentro de 7 días, una revisión silenciosa es normal, no está atascada. El texto de Google permite de forma explícita que las revisiones a veces tarden más que la ventana habitual. Actúa cuando esa ventana se haya pasado con claridad: verifica que la versión se envió de verdad a revisión, mira el correo del titular de la cuenta incluido el spam, y solo entonces contacta al soporte de Play Console.
"Atascada" casi siempre resulta ser una de tres cosas: una revisión que aún está dentro de su rango normal, una versión que nunca se envió de verdad, o una decisión que ya llegó a una bandeja que nadie revisó. Pasa tu situación por el chequeo antes de asumir lo peor:
Elige qué estás esperando y cuánto lleva. El veredicto usa las ventanas que Google declara, no el folklore de foros.
¿Qué estás esperando?
¿Cuánto tiempo lleva?
Diga lo que diga el chequeo, la ruta de escalamiento son los mismos cuatro movimientos, en orden:
-
1
Confirma que de verdad está en revisión
Abre el resumen de publicación en Play Console. Una versión guardada como borrador, o cambios nunca enviados a revisión, no revisa nada. Este solo paso resuelve una gran parte de los casos "atascados".
-
2
Revisa el correo del titular de la cuenta, incluido el spam
Google envía las decisiones al titular de la cuenta, no necesariamente a la dirección que miras a diario. Un rechazo de hace una semana en el spam se ve exactamente como una revisión atascada desde dentro del Console.
-
3
Espera la ventana declarada antes de escalar
Dentro de 7 días, escalar no compra nada: la revisión se comporta como está documentado. Marca el día en que pasa la ventana y actúa entonces, no antes.
-
4
Contacta al soporte de Play Console
Pasada la ventana habitual, con envío confirmado y bandeja vacía, usa el menú Ayuda de Play Console para llegar al soporte. Si la respuesta que llega al final es un rechazo, empieza por por qué se rechaza la prueba cerrada antes de reenviar.
Del primer upload a app en vivo: un cronograma realista
Suma las etapas y una cuenta personal de desarrollador nueva suele necesitar de 3 a 5+ semanas desde la creación de la cuenta hasta la app en vivo. La fase de prueba en sí es aritmética más apretada: con testers que aceptaron participar el día uno, la solicitud de acceso a producción cae alrededor del día 15, y la revisión de Google de suele ser 7 días o menos pone una decisión con frecuencia dentro de la tercera semana de prueba. Las etapas pueden solaparse, y un rechazo alarga el total.
Ese número no es una estadística inventada; son los componentes de Google sumados. La verificación de identidad tarda unos días. La revisión de la primera versión de prueba cerrada tarda hasta 7 días. La prueba cerrada tarda exactamente 14 días una vez que arranca. La revisión de acceso a producción suele tardar 7 días o menos. La revisión final de la versión suele ser rápida pero puede sumar días. Ponlos uno tras otro:
La brecha entre tres semanas y cinco o más se decide casi por completo en dos puntos: qué tan rápido aceptan participar de verdad tus 12 testers, porque la ventana se abre con la participación aceptada número 12 y no con tu upload, y si alguna revisión vuelve como rechazo, porque cada rebote repite un ciclo de revisión. Todo lo demás es matemática fija. Proyecta tus propias fechas:
Elige dónde estás hoy. Las fechas se calculan a partir de las ventanas que declara Google, asumiendo que tu racha de prueba no se rompe.
¿Dónde estás hoy?
Cómo encaja PrimeTestLab
PrimeTestLab comprime el único reloj que controlas. Las ventanas de revisión de Google son iguales para todos; la etapa que de verdad separa un lanzamiento de tres semanas de uno de seis es la prueba cerrada, y esa es la etapa que un roster gestionado lleva sobre rieles: testers que aceptan participar en 4-6 horas, se mantienen activos los 14 días completos y las bajas se reponen el mismo día.
Una nota honesta sobre el timing: Google controla los relojes de revisión, no nosotros. Su propia guía es que la revisión de acceso a producción "usually takes 7 days or less, but may occasionally take longer", y ningún servicio cambia eso. Lo que controlamos es la ventana de prueba: arrancarla en 4-6 horas en lugar de después de semanas de reclutamiento, y evitar que se reinicie.
Así se reparte el trabajo crítico de calendario cuando operas la ventana tú mismo frente a entregarla a un roster gestionado:
| Factor de calendario | Hazlo tú mismo | Con PrimeTestLab |
|---|---|---|
| Tiempo hasta 12 testers con participación aceptada | Días a semanas de reclutamiento antes de que abra la ventana | El roster acepta participar en 4-6 horas, fines de semana incluidos |
| Mantener viva la racha de 14 días | Una baja por debajo del mínimo puede reiniciar la ventana | Monitoreo diario, reposición de bajas el mismo día |
| Dispositivos reales que cuentan | Tú verificas la configuración de cada tester | Dispositivos reales de Android 7 a 17, en 120+ países |
| Preparación del cuestionario | Escribes las tres secciones solo, desde cero | Guía de respuestas probada tras el día 14 |
| Relojes de revisión de Google | Idénticos para todos | Idénticos para todos. Nadie puede comprar una revisión más rápida |
| Costo | Gratis, pero el calendario paga en su lugar | Desde $19.99, un pago por app |
Los planes empiezan en $19.99 por 12 testers, con rosters más grandes que añaden un colchón de seguridad sobre el mínimo. Ve el servicio de prueba cerrada para lo que incluye una corrida gestionada, o el proceso paso a paso. Tu costo de tiempo propio es de unos 7 minutos en dos sesiones cortas.
Los precios excluyen un 5% de tarifa de servicio que se suma al pagar. Si Google no concede el acceso a producción tras el ciclo completo, eliges repetición gratis o reembolso completo.Preguntas frecuentes sobre tiempos de revisión de Google Play
¿Cuánto tarda la revisión de Google Play en 2026?
No hay un solo número. Las versiones de pruebas internas suelen estar disponibles en minutos, la primera versión de la prueba cerrada puede tardar hasta 7 días de revisión manual, la revisión de acceso a producción suele tardar 7 días o menos según el texto de Google, y las revisiones estándar de app o actualización suelen ser rápidas, pero pueden tardar hasta 7 días o más en casos excepcionales. La prueba cerrada de 14 días en el medio es una ventana de prueba que operas tú, no una cola de revisión.
¿Cuánto tarda la revisión de acceso a producción?
Google indica que la revisión de acceso a producción suele tardar 7 días o menos, aunque en ocasiones puede tardar más. Solicitas el acceso después de que tu prueba cerrada cumpla los requisitos, respondes un cuestionario de tres secciones sobre tu prueba cerrada, tu app y la preparación para producción, y Google envía la decisión por correo al titular de la cuenta.
¿Cuánto dura la prueba cerrada en Google Play?
Planifica unas dos semanas y media como piso. Tu primera versión de prueba cerrada puede pasar hasta 7 días en revisión, y esos días no cuentan para el requisito. La prueba en sí necesita al menos 12 testers que hayan aceptado participar durante 14 días de forma continua, y el reloj en la práctica arranca cuando el tester número 12 acepta participar. En la documentación oficial de Google en español, a los testers también se les llama verificadores. Con testers listos el día uno, la solicitud de acceso a producción cae alrededor del día 15 de prueba.
¿Los 14 días de prueba cerrada cuentan como tiempo de revisión?
No. Nada se revisa durante los 14 días; es una ventana de prueba que operas manteniendo a tus testers con participación aceptada y activos de verdad. Google revisa tu app antes de que abra la ventana, cuando se aprueba la primera versión en el canal cerrado, y después de que cierra, cuando solicitas acceso a producción. Ninguna de esas revisiones se solapa ni acorta los 14 días.
¿Por qué tarda tanto la revisión de mi primera versión de prueba cerrada?
Las primeras versiones en un canal de pruebas cerradas pasan por una revisión manual de Google que puede tardar hasta 7 días, lo que sorprende a quien espera el comportamiento casi instantáneo de las pruebas internas. Dentro de esa ventana, una revisión silenciosa es normal. Esos días de revisión no cuentan para tu requisito de 14 días de prueba, así que sube el primer build en cuanto esté estable.
¿Puedo acelerar una revisión de Google Play?
No de forma directa. Google no documenta un carril de pago ni una solicitud de prioridad para revisiones estándar. Lo que sí controlas es evitar un segundo pase: completa todas las declaraciones, da acceso demo que funcione si tu app pide login y presenta una historia de prueba clara. Un primer envío limpio es la forma más fiable de mantener el tiempo de revisión en el lado corto.
¿Qué hago si mi app lleva más de 7 días atascada en revisión?
Primero confirma que de verdad está en revisión: revisa el resumen de publicación en Play Console y asegúrate de que los cambios se enviaron a revisión, porque un borrador guardado no se revisa. Mira el correo del titular de la cuenta, incluido el spam, porque ahí manda Google las decisiones. Pasada la ventana habitual de 7 días sigues dentro del margen de que "en ocasiones puede tardar más", pero en ese punto es razonable contactar al soporte de Play Console desde el menú Ayuda.
¿Las actualizaciones de la app necesitan otra prueba cerrada con 12 testers?
No. El requisito de prueba se cumple una vez por app, así que las actualizaciones rutinarias de una app que ya tiene acceso a producción no necesitan una prueba cerrada nueva. Las actualizaciones sí pasan por la revisión normal de Google, que suele ser rápida pero sin plazo prometido. Durante una prueba cerrada, subir un build actualizado tampoco reinicia el reloj de 14 días.
¿Cuánto tarda todo el proceso desde cuenta nueva hasta app en vivo?
Suele ser de 3 a 5+ semanas para una cuenta personal de desarrollador nueva: la verificación de identidad tarda unos días, la revisión de la primera versión de prueba cerrada hasta 7 días, la prueba cerrada en sí 14 días, la revisión de acceso a producción suele ser de 7 días o menos, y la revisión de la versión final suele ser rápida pero puede sumar días. Las etapas pueden solaparse. La mayor variable es qué tan rápido aceptan participar tus 12 testers; con un roster gestionado que arranca en 4-6 horas, la fase de prueba ronda unos 15 días desde el pedido hasta la solicitud de acceso a producción.
Conclusión
Resumen
El tiempo de revisión de Google Play en 2026 son cinco relojes, no uno. Las versiones internas aparecen en minutos; tu primera versión de prueba cerrada puede quedarse en revisión manual hasta 7 días; la prueba cerrada de 14 días no es una revisión sino una ventana que operas; la revisión de acceso a producción suele tardar 7 días o menos; y las revisiones de versión o actualización no tienen plazo prometido. De punta a punta, una cuenta personal de desarrollador nueva suele necesitar de 3 a 5+ semanas desde la creación de la cuenta hasta la app en vivo, y el factor de balanza es la prueba cerrada: reclutar testers tarde, o perder uno a mitad de ventana, cuesta más días que cualquier revisión. Los relojes de Google no se compran ni se apresuran. El tuyo sí se puede operar bien desde la primera hora: PrimeTestLab arranca tu prueba en 4-6 horas y mantiene la racha intacta hasta el día 14, para que la única espera sea la que nadie puede evitar. Mira cómo funciona el servicio de prueba cerrada →