La odisea de las reviews en la App Store

Al momento de escribir este artículo, tengo dos años de experiencia desarrollando aplicaciones móviles. He implementado arquitecturas en la nube, desarrollado backends y desplegado más de 10 aplicaciones a la Play Store y a la App Store.

He aprendido haciendo y deshaciendo; cometiendo errores. Y una de las cosas más frustantes para mí es subir una aplicación a la App Store; no porque sea tedioso hacerlo (lo es), sino por lo que viene después: La ansiedad constante de no saber si la aprobarán o no; y el estrés de ser rechazado constantemente, haciendo que se retrase la fecha de publicación de la app. En algún momento he sentido lo mismo que Verry

Hay muchas cosas muy básicas por las que pueden rechazar tu app: tienes un bug, es una app clonada, la interfaz es pobre, contenido inapropiado, etc. Todo esto lo puedes saber dando una leída rápida al App Store Review Guidelines. El problema es que este documento es largo y tedioso de leer. Además, es como un listado de leyes que son interpretadas por los revisores de Apple. Así que hay motivos que no están del todo claros en este documento, pero que gracias a la “interpretación” los revisores rechazan tu aplicación.

Aquí te mostraré algunos casos por los que han rechazado mis aplicaciones y que siempre hay que tener en cuenta desde la etapa de diseño (o hasta en etapas anteriores).

Sign in with Apple

Este es uno de los más sencillos, pero siempre es necesario implementarlo en la mayoría de las apps. Se debe agregar el botón de inicio de sesión de Apple siguiendo sus lineamientos gráficos. Es obligatorio si usas otro inicio de sesión que no sea correo/contraseña: Google, Facebook, Github, etc.

Mapa de iOS

Este punto es un poco más restrictivo que el de arriba. Si tu aplicación utiliza un mapa para cosas sencillas, por ejemplo, hacer que el usuario coloque una ubicación o colocar puntos en el mapa, es obligatorio que uses lo servicios de mapas que ofrece Apple. Sólo puedes usar otros servicios si utilizas funciones especializadas; las funcionalidades de la API de Google Maps, por ejemplo.

Datos personales opcionales

Cuando registras a un usuario por primera vez, muchas veces solemos pedir información personal de más: DNI, género, día de nacimiento, etc. Información que tal vez no es tan relevante para la funcionalidad de nuestra aplicación. Pues, Apple nos dice que si no tenemos una razón totalmente válida para obligar al usuario a colocar esos datos, entonces debemos colocarlos como opcionales o de plano no pedirlos.

Y hay que ser bien concientes de ello. Por ejemplo, para que te acepten colocar como obligatorio el DNI, necesitas que en tu aplicación sea indespensable el uso del DNI, en otras palabras, sin DNI tu aplicación no funciona. Así que, para evitarnos problemas, si tu aplicación puede funcionar sin algún dato que pueda considerarse como personal, entonces es mejor colocarlos como opcional.

Rellenar datos de registro

Este aplica si es que tienes un inicio de sesión con Apple o con terceros. Si al momento de registrar al usuario, pides datos como el nombre, apellido, correo … estos tienen que venir de la cuenta de Apple o de terceros con la que el usuario ha iniciado sesión y estos campos se deben rellenar automáticamente en la aplicación.

Ingreso como invitado

Si no es necesario que el usuario esté logueado para poder realizar algunas funciones dentro de la aplicación, entonces no deberías obligarlo o deberías tener un inicio de sesión como invitado. Un ejemplo muy claro son las aplicaciones E-commerce, donde no es necesario que estes logueado para ver los productos.

Hay que tener cuidado con este punto, ya que los revisores de Apple son muy estrictos con esto. Y si no se toma en cuenta desde el inicio, puede que rearmar la aplicación para entrar sin inicio de sesión sea muy complicado.

Ha pasado que un cliente armó una aplicación de venta de productos, en donde para él era muy importante el registro de los usuarios (por la ubicación y la información del usuario). Apple rechazó su aplicación y por más que explicó y raclamó no la aceptaron. Lo más rápido que pudo hacer fue habilitar un botón de “Ingresar como invitado” al inicio de su aplicación. Por esta razón, este punto es muy importante tenerlo en cuenta desde la planeación de la aplicación.

Rellenar con data real

Supongamos que tienes una app en donde la gente puede registrarse y vender sus cosas y comprar las de otros. Y no tienes usuarios o los únicos usuarios son tu equipo de trabajo, y en la pantalla principal no hay más de 4 productos. Si subes así la aplicación te la van a rechazar, necesitas que la aplicación esté lista para usarse y Apple ve que con 4 productos tu app no esta lista para usarse. Tienes que registrar más usuarios y que generen más data.

Para resolver esto, puedes subir la app a TestFlight y ponerla en una beta abierta; en beta abierta también revisan la app, pero son mucho más flexibles ahí. Ya en beta abierta puedes pasar el link a un circulo cercano que pueda generar contenido.

Otra cosa a tener en cuenta es que en ningún lugar de la aplicación ni en el contenido debe decir “test” o “prueba” o cualquier cosa que haga pensar que es contenido de prueba, funcionalidad de prueba o que la aplicación es de prueba.

El primer loading cuenta

Los reviewers de Apple prueban tu aplicación con una conexión a internet inestable. Así que la pantalla de carga al momento de entrar a tu aplicación por primera vez es muy importante: ¡No puede quedarse cargando por mucho tiempo! Para esto puedes dejar que entre a la aplicación y hacer que los datos se carguen de forma asíncrona o si es necesario cargar datos antes de entrar a la aplicación, debes poner un timeout que avise al usuario que su conexión es inestable y no se pueden cargar los datos. Con eso basta.

Screenshots

Tambien te pueden rechazar por la información que pones en la página de tu aplicación y es más común que rechacen por los screenshots. La regla de oro de los screenshots es que debes mostrar la funcionalidad tal cual como se vería en un dispositivo iOS. Puedes agregar texto o imágenes, siempre y cuando venga acompañado con screenshots de la aplicación en un iOS. ¡Nunca subas screenshots tomados en Android! La forma más fácil de abordar esto es tomar screnshots del emulador de iOS.

¡Todo debe funcionar!

No debe de haber ningún error visible en la aplicación, todas las pantallas deben estar totalmente funcionales con y sin internet, no debe haber ninguna imagen, video ni link roto en la aplicación; todo debe funcionar. Esta parte es más una recomendación para que se testee toda la aplicación antes de subirla a cualquier tienda.

Y con todos estos puntos aumentará tu posibilidad de recibir el esperado mensaje de aceptación de la app.