Los rechazos más comunes de las tiendas

Los de Apple

1. Cuenta de prueba que no funciona. Quien revisa tiene que poder entrar. Si la app tiene login y no dejaste usuario y contraseña válidos en las notas de revisión, el rechazo es seguro. Comprueba ese acceso el día del envío, no la semana anterior.

2. Privacidad que no coincide. Lo que la app recopila tiene que ser lo que la ficha dice que recopila, y la política de privacidad debe vivir en una dirección que abra.

3. No se puede borrar la cuenta. Si la app deja crear cuenta, tiene que dejar borrarla desde dentro. De los más fáciles de evitar y de los más comunes de recibir.

4. "Esto es un sitio web envuelto." Una app que es solo tu web en un marco, sin nada que justifique estar en la tienda, se rechaza. Si tu caso es contenido y formulario, el camino honesto suele ser publicar en la web.

5. Pago por fuera. El contenido digital consumido dentro de la app tiene que pasar por la compra de la tienda. El producto físico y el servicio prestado fuera, no. Confundirlos es rechazo y a veces retirada.

6. Contenido de usuario sin frenos. Si la gente escribe, publica o conversa, la app necesita filtro, denuncia, bloqueo y contacto. Sin los cuatro, no pasa.

Los de Google

1. Formulario de seguridad de los datos incorrecto. El campeón. Lo que declaras tiene que coincidir con lo que hace la app, incluido lo que envían fuera las bibliotecas de terceros.

2. Permisos sin justificación. Ubicación, cámara, contactos: cada permiso pedido necesita una función visible que lo use. Un permiso sobrante es un rechazo.

3. Nivel de API antiguo. La exigencia sube cada año. Una app por debajo del mínimo ni se publica ni se actualiza.

4. Prueba cerrada sin completar. Las cuentas nuevas de desarrollador particular necesitan el periodo de prueba con probadores antes de publicar. No es un rechazo de contenido, es un requisito previo, y retiene el lanzamiento.

5. Política de privacidad ausente. Una dirección pública que abra, con el texto de verdad.

Qué hacer antes de enviar

• entra con la cuenta de prueba que escribiste en las notas, el día del envío;
• abre la política de privacidad en una ventana privada;
• repasa permiso por permiso: ¿cada uno tiene una pantalla que lo usa?
• confirma que el formulario de datos dice lo que hace la app;
• si hay cuentas, busca el botón de borrar la cuenta;
• si hay contenido de usuario, busca el botón de denunciar.

Seis comprobaciones, quince minutos, y cubren la mayoría de los rechazos de esta lista.

El resumen

• el rechazo es común y casi siempre de papeleo, no de código;
• en Apple: cuenta de prueba, privacidad, borrado de cuenta, "web envuelta", pagos y contenido de usuario;
• en Google: formulario de datos, permisos sobrantes, nivel de API y prueba cerrada;
• el costo del rechazo es calendario, y por eso comprobar antes compensa;
• si la app es contenido y formulario, quizá ni necesite la tienda.