Rechazo en Google Play
Google rechazó la versión porque su revisor no pudo pasar de tu pantalla de inicio de sesión. En la app no hay nada roto; el revisor simplemente no tenía una forma de entrar que funcionara. Añade una cuenta de prueba reutilizable en la Play Console, en Datos de inicio de sesión (Sign-in details, la sección que las guías antiguas llaman Acceso a la aplicación o App access), asegúrate de que se salta los códigos de un solo uso y los enlaces por email, y vuelve a enviarla.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
Los revisores de Google tienen que ver todo lo que hace tu app. Si alguna parte está restringida por un inicio de sesión, una membresía, una ubicación u otra forma de autenticación, debes darles lo que necesiten para entrar: credenciales de prueba, una cuenta demo o instrucciones para códigos y otros casos especiales. Esto se introduce en la Play Console en Política y programas → Contenido de la aplicación → Datos de inicio de sesión (Policy and programs → App content → Sign-in details). Las guías antiguas, los foros, algunos avisos y la ayuda de Google en español todavía llaman a esta sección Acceso a la aplicación (App access); es lo mismo. Puedes guardar hasta cinco conjuntos de instrucciones, cada uno con los datos de acceso y un campo Otras instrucciones (Any other instructions) para todo lo que tenga de especial tu inicio de sesión.
Los requisitos de Google para los datos de inicio de sesión son breves y estrictos. Las credenciales deben estar disponibles en todo momento, ser reutilizables, válidas desde cualquier país, seguir funcionando y estar en inglés (o incluir una versión en inglés). Si tu inicio de sesión normalmente requiere una contraseña de un solo uso o un segundo factor, debes proporcionar credenciales que se salten ese paso. Un inicio de sesión por código QR necesita en su lugar una URL estática, y el contenido tras un paywall necesita instrucciones que permitan al revisor usar libremente la parte de pago. Una contraseña que caduque durante la revisión puede hacer que rechacen la app.
La entrada en Estado de las políticas (Policy status) suele titularse algo como Need login credentials for app review. Explica que el revisor no pudo acceder a toda la app o a parte de ella y pide una cuenta demo activa, además de cualquier otro recurso necesario para la revisión, como códigos. La captura adjunta suele mostrar tu pantalla de inicio de sesión, una página de confirmación de email o un mensaje de "revisa tu bandeja de entrada".
La misma causa de fondo se esconde también detrás de otros rechazos. Un revisor atascado en el login puede clasificar la app por funcionalidad mínima, porque un formulario de inicio de sesión es todo lo que vio (la guía de funcionalidad mínima cubre el resto de ese rechazo). Una declaración de ubicación en segundo plano, de eliminación de cuenta o de otra función puede denegarse porque el revisor no pudo verificar la función que hay detrás del login. Antes de reescribir cualquier otra cosa, comprueba si el revisor llegó a entrar.
Los builders de IA generan por defecto una autenticación moderna y sin contraseña. Es estupenda para los usuarios y un callejón sin salida para un revisor con un dispositivo de prueba recién configurado.
Los enlaces por email sin contraseña son una opción por defecto habitual en las apps basadas en Supabase y en muchos kits de autenticación. El revisor no tiene acceso a la bandeja de entrada de tu cuenta de prueba y, en un teléfono, el enlace se abre de todos modos en el navegador o en la app de correo en lugar de en tu WebView, como explica la guía de magic links.
Un código de seis dígitos enviado por email o SMS a una dirección que solo controlas tú detiene la revisión en seco. Google pide credenciales reutilizables que se salten el paso del código.
Dentro de un WebView, Google rechaza su propia página de inicio de sesión a menos que esté configurado el login helper de WebViewGold (GOOGLE_LOGIN_HELPER_TRIGGERS, consulta la solución para disallowed_useragent). Incluso cuando funciona, un revisor no va a usar una cuenta personal de Google. Ofrece también email y contraseña.
Las listas de espera, los códigos de invitación y los flujos del tipo "un administrador aprobará tu cuenta" hacen que un registro nuevo nunca llegue al producto. Aprueba de antemano la cuenta de revisión.
Los bloqueos por país, las reglas de firewall estrictas, los desafíos antibots agresivos o los límites de frecuencia en la ruta de login pueden frenar el dispositivo de un revisor. Google espera credenciales que funcionen sea cual sea la ubicación.
La caducidad de las pruebas gratuitas, las tareas de limpieza de usuarios inactivos y tu propio flujo de eliminación de cuenta (que un revisor puede probar) pueden borrar la cuenta entre dos revisiones.
Mi WebView de iOS finalmente está aprobada. ¡Gracias!
Unos treinta minutos una sola vez; después sirve para cada actualización.
Usa una dirección como [email protected] que exista solo para las revisiones de las tiendas. Nunca entregues tu propio login ni el de un cliente real: Google pide credenciales creadas para pruebas. Marca el email como confirmado en el panel de tu proveedor de autenticación para que no haga falta ningún correo de confirmación.
Si tu app inicia sesión solo con magic link o con código de un solo uso, añade una opción normal de email y contraseña que cualquier usuario pueda elegir, por ejemplo un enlace "Usar una contraseña" debajo del campo de email (el prompt de abajo lo hace por ti). El login por teléfono a menudo puede usar un número de prueba fijo: Firebase Authentication, por ejemplo, te permite registrar números de teléfono de prueba con un código de verificación fijo. Escribe los pasos exactos en las instrucciones.
Añade contenido de ejemplo realista para que cada pantalla muestre su propósito, y concede el acceso de pago en tu servidor para que las pantallas premium se puedan revisar sin comprar nada. Si tu app tiene roles (cliente y proveedor, miembro y administrador), crea una cuenta por rol y usa un conjunto de instrucciones para cada una.
Excluye la cuenta de los scripts de limpieza y de la caducidad de las pruebas. Después de cada revisión, inicia sesión una vez para comprobar que sigue existiendo; un revisor que pruebe tu flujo de eliminación de cuenta puede haberla usado. Un pequeño script que vuelva a crear la cuenta con sus datos de ejemplo te ahorra un rechazo.
Permite la ruta de login desde todos los países y asegúrate de que la protección antibots no le plantee un desafío a un dispositivo Android recién configurado en su primer arranque. Si tu servicio solo opera en un país, mantén al menos la cuenta de revisión funcionando en todo el mundo e indícalo en las instrucciones.
Abre Política y programas → Contenido de la aplicación → Datos de inicio de sesión, elige Empezar o Gestionar y luego Añadir instrucciones nuevas. Pega las credenciales exactamente como se escriben en la pantalla de inicio de sesión y usa Otras instrucciones (Any other instructions) para todo lo inusual: qué botón hay que tocar, cómo se salta el paso del código, qué rol tiene la cuenta y dónde están las funciones principales.
Desinstala la app, instala la compilación del canal de pruebas internas e inicia sesión pegando las credenciales desde la Play Console. Si CLEAR_CACHE_ON_STARTUP está en true en Config.java, la app borra las cookies en cada inicio, así que el revisor vuelve a iniciar sesión después de cada arranque; menciónalo. Si el bloqueo de la app (enableBioMetricAuth) está activado, menciónalo también y prueba en un dispositivo sin huellas registradas para saber qué verá el revisor. Ambas opciones se describen en la referencia de Config.java para Android.
Si solo cambiaron los datos de inicio de sesión, guárdalos y envía la actualización a revisión; la Play Console muestra los cambios pendientes en el Resumen de publicación (Publishing overview). Si cambiaste la app, por ejemplo para añadir la opción de contraseña, sube una nueva versión con un version code más alto. Ayuda dejar una respuesta de una línea en Estado de las políticas que remita a las nuevas instrucciones.
Inglés sencillo, pasos numerados, nada de marketing. El revisor lo lee mientras tiene la app abierta en un dispositivo de prueba. La plantilla se queda en inglés porque los revisores de Google la leen en inglés.
Login method: email and password. On the start screen tap [Log in], then [Use a password instead] below the email field. This account is pre-confirmed and needs no one-time code or email link. It works from any country. Role: [customer]. A second instruction set contains the [provider / admin] account. The account has the [Pro] plan unlocked on our server, so all paid features are visible without a purchase. Where to find the main features: 1. [Bookings tab]: create and cancel a booking. 2. [Profile > Notifications]: turn on reminders; a test notification arrives within [2] minutes. 3. [Profile > Settings > Delete account]: account deletion. Please use the second test account for this, so the main account stays available for future reviews. The app asks for [location] only on the [Store finder] screen, after an in-app explanation. [Only if enabled:] The app is protected by an app lock on launch; [describe what appears on a device without fingerprint or face unlock]. Contact during review: [email address].
Conserva tu flujo de magic link o de código y añade un login normal con contraseña que cualquier usuario puede usar. Es lo que necesita el revisor, y no es una puerta trasera oculta.
Mi app inicia sesión actualmente con [magic links / códigos de un solo uso por email] a través de [Supabase Auth / Firebase Auth / Clerk]. Añade un inicio de sesión estándar con email y contraseña junto al método existente, sin eliminarlo: - En la pantalla de inicio de sesión, añade un enlace bien visible 'Usar una contraseña' que cambie el formulario a email + contraseña. - Añade 'Crear una contraseña' en los ajustes de la cuenta, para que los usuarios existentes puedan crear una. - Usa el inicio de sesión con contraseña integrado del proveedor de autenticación. No construyas ningún acceso alternativo propio, secreto u oculto. - Muestra un error claro si la contraseña es incorrecta e incluye un flujo de 'He olvidado mi contraseña'. - Mantén la sesión persistente entre reinicios de la app; la app se ejecuta dentro de un WebView de Android. - No cambies nada más. Al final, enumera los archivos que cambiaste y explícame cómo creo un usuario de prueba preconfirmado con contraseña en el panel de [proveedor].
Solo si el registro funciona al instante, sin confirmación por email, códigos ni aprobación, e incluso entonces Google espera credenciales cuando hace falta iniciar sesión. Dar una cuenta lista es más rápido y evita un segundo rechazo.
No, si es una opción normal y visible que cualquier usuario puede usar. Lo que debes evitar es un código o una ruta secretos que desbloqueen un comportamiento distinto para los revisores; eso entra en las normas sobre comportamiento engañoso.
La solución robusta es añadir email y contraseña. Una cuenta de Google dedicada a la revisión suele toparse con pasos de verificación adicionales al iniciar sesión en un dispositivo nuevo, y el inicio de sesión con Google en un WebView necesita el login helper de WebViewGold para funcionar siquiera.
Solo cuando algo cambie, pero cada actualización se revisa con los datos que tengas guardados. Mantén la cuenta válida de forma permanente y actualiza las instrucciones cada vez que añadas un rol, un paywall o una función principal nueva.
Solo si le das una cuenta real, cosa que no deberías hacer. Google pide credenciales creadas para pruebas. Usa datos de ejemplo que muestren para qué sirve cada pantalla.
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principal$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuita$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.
Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días
¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.
