App Store y Google Play: cómo evitar el rechazo
La mayoría de los rechazos vienen de una preparación incompleta, no de código roto. Lo que debe estar listo antes de enviar, para ambas tiendas.
Equipo de rabbitclipPublicación: 5 min. de lectura
En breve
La mayoría de los rechazos en App Store y Google Play no vienen de código roto sino de una política de privacidad faltante, una solicitud de permiso sin explicar, o una cuenta de prueba faltante. Cuando eso está listo antes del envío, la app suele pasar la revisión a la primera.
Las dos tiendas revisan de forma distinta. Apple se apoya en revisión humana y es más estricta; Google se apoya más en escaneo automatizado, pero actúa con la misma firmeza ante infracciones de políticas. Cada una necesita su propia preparación.
Qué debe estar listo antes de enviar
Una política de privacidad es obligatoria en ambas tiendas, y debe reflejar de verdad los datos que la app recopila; una plantilla copiada y pegada suele causar problemas en la revisión.
Si la app solicita un permiso (ubicación, cámara, notificaciones), una breve explicación de por qué lo necesita debe ser visible tanto para el usuario como para el revisor. Apple busca esto de forma específica.
- Una política de privacidad (accesible mediante una URL activa)
- Explicaciones de permisos (ubicación, cámara, notificaciones, contactos)
- Una cuenta de prueba para la revisión (en apps que requieren inicio de sesión)
- Capturas de pantalla y texto de tienda que reflejen la interfaz real
Por qué Apple rechaza apps
Entre los motivos de rechazo más comunes de Apple están la funcionalidad incompleta (fallos, pantallas en blanco), un permiso sin explicar y violaciones de las reglas de compras integradas. El revisor usa la app de verdad; si la cuenta de prueba no funciona, viene el rechazo.
Otro motivo frecuente es que la app parezca un simple envoltorio alrededor de un sitio web. Apple quiere ver un valor nativo genuino; eso hace que cuidar la interfaz y la experiencia valga la pena.
Por qué Google Play rechaza apps
Del lado de Google, el problema más común es un formulario Data Safety que no coincide con lo que la app realmente recopila. Si ese formulario se completa de forma incompleta o incorrecta, los sistemas automatizados lo marcan.
El nivel de API objetivo también debe mantenerse al día; Google eleva el nivel mínimo de API objetivo cada año, y las apps que se quedan en un nivel antiguo pueden perder la capacidad de instalarse o actualizarse.
La experiencia de un fabricante de ropa de trabajo
La app de pedidos B2B de un fabricante de ropa de trabajo fue rechazada en el primer envío porque no se explicaba el motivo de la solicitud de permiso de ubicación. Se añadió una explicación y se reenvió la misma versión ese mismo día; pasó la segunda revisión.
Es un ejemplo útil: el rechazo suele venir no de mal código sino de algo que un revisor no pudo ver explicado. Dejar bien armada la lista de preparación desde el principio evita la mayoría de los rechazos.
El criterio de decisión aquí fue simple: para cada permiso que la app solicitaba, se escribió una respuesta de una frase a 'para qué sirve realmente este permiso en la app'. Ese único paso hizo que el segundo envío pasara sin problemas tanto en Apple como en Google.
Cómo prepararse: paso a paso
Tratar la preparación del envío como una secuencia en lugar de una lista de una sola vez reduce el riesgo en ambas tiendas. El primer paso es listar cada permiso que solicita la app y redactar de antemano la explicación que verá el usuario para cada uno; esto puede hacerse ya en la etapa de diseño, antes de terminar el desarrollo.
El segundo paso es crear una cuenta de prueba que funcione de verdad para cada pantalla que requiera inicio de sesión, y recorrer la app de principio a fin como lo haría un revisor. El tercero es contar cada dato que la app realmente recopila, incluida cualquier herramienta de analítica o servicio de notificaciones, al completar el formulario Data Safety de Google Play; incluso un servicio de terceros olvidado puede invalidar todo el formulario.
El último paso es comprobar que las capturas de pantalla del envío y el texto de la tienda coinciden exactamente con la interfaz actual de la app; una captura de pantalla de un diseño anterior es un motivo de rechazo pequeño pero sorprendentemente frecuente.
Errores frecuentes
El error más frecuente es redactar la política de privacidad y las explicaciones de permisos en el último momento, la noche antes del envío, una vez terminado el desarrollo; un texto escrito con prisa tiende a convertirse en frases genéricas que no satisfacen ni al revisor ni al usuario.
El segundo es suponer que una versión aprobada en una plataforma pasará también en la otra sin cambios. Apple y Google miran cosas distintas; una explicación de permiso que satisface a Apple puede dejar incompleto el formulario Data Safety de Google. Cada tienda debe prepararse según sus propios criterios.
- Dejar la política de privacidad y los textos de permisos para el último momento
- Suponer que la preparación suficiente para una tienda basta para la otra
- Crear la cuenta de prueba justo antes del envío, sin probarla de verdad
Cuánto tarda la revisión
La revisión de Apple suele resolverse en pocos días, pero un ciclo de rechazo y reenvío alarga ese plazo. La revisión automatizada de Google es más rápida, pero las apps marcadas por un problema de políticas pasan a revisión manual y pueden tardar más.
El rechazo en tienda suele ser una carencia de preparación, no un problema de código; cuando la política de privacidad, las explicaciones de permisos y la cuenta de prueba están completas desde el principio, el proceso avanza sin sobresaltos. Si va a enviar por primera vez o a reenviar con una actualización, vale la pena repasar juntos esta lista.
Preguntas frecuentes
¿Cuánto tarda la revisión del App Store?
Por lo general unos pocos días; no hay un tiempo garantizado y varía según el volumen de revisión.
¿Por qué importa tanto el formulario Data Safety en Google Play?
Si los datos declarados en el formulario no coinciden con lo que la app realmente recopila, los sistemas automatizados lo marcan, lo que puede llevar a rechazo o suspensión.
¿Se puede enviar una app sin cuenta de prueba?
No en apps que requieren inicio de sesión; el revisor o el sistema debe poder usar la app de verdad.
¿El proceso vuelve a empezar tras un rechazo?
No, normalmente se corrige el problema señalado, se reenvía la misma versión y vuelve a entrar en la cola de revisión.
