11 cosas que hay que comprobar antes de publicar una app [checklist gratis]
En esta entrada os ofrecemos un útil checklist para que uséis antes de publicar una app, así no se os escapará nada 
Como sabéis, cuando publicamos una app para Google Play, esta es publicada al instante, sin pasar por ningún filtro. En cambio, cuando publicamos una app en el App Store, esta pasa antes por el filtro de los revisores de Apple. ¿Qué miran los revisores? Si la app cumple con lo prometido, si funciona, si cumple con una política de privacidad (en caso necesario) y otras cosas. Aunque Google no mire si nuestra app cumple con estos mínimos, nosotros mismos tendremos que ser lo suficientemente serios como para publicar apps con un mínimo de decencia en las tiendas de apps. A continuación, encontraréis una lista con lo que tenemos que tener en cuenta antes de publicar una app y ofrecerla a los usuarios:
1) Testing. ¿Hemos hecho testing con usuarios reales?
Muchas veces la emoción nos puede. Ya está, ya está, por fin hemos terminado la app. Hemos ido de A a Z, sin testear apenas nada. Por las prisas. Porque el cliente quería el proyecto en 2 semanas. Porque el evento en el que queremos presentar la app va a celebarse tal día y si no enviamos la app hoy al App Store, esta no verá a luz el día en cuestión. Claro… pero sin testing quizá no ve la luz ni en 20 días. Puede ocurrirnos que el día en cuestión en el que creemos que saldrá la app, esta siga aún en revisión por 2º vez por tener que arreglar una “tontería”.
¡Por favor! Testeemos con usuarios reales. Ellos nos sabrán decir -sin decirlo claramente, sólo tendremos que observarlos- dónde nos hemos equivocado. Incluso, gracias a ellos, veremos errores garrafales que se nos habían pasado por alto.
3) ¿Tenemos las cuentas en las tiendas de apps al día?
Contratos por aceptar. Licencias por pagar. No sería la primera vez que alguien decide publicar una app -enviarla a revisión al App Store- y se encuentra con que tiene caducado su ‘membership’ como iOS Developer. Mejor tener todo esto controlado si nos corre la prisa para poder publicar la app. Lo mismo con los certificados: duran lo que duran (1 año), así que mejor tenerlo todo al día si queremos poder hacer testing con facilidad y poder enviar a clientes pruebas Ad Hoc con agilidad y rapidez.
4) ¿Tenemos una Marketing URL?
Es una web que se nos pide cuando publicamos una app para poder hacer promoción de la misma en las tiendas de apps. En esta URL hay más información sobre la app en cuestión y, además, nos sirve también como método de promoción de la app en el mundo de la web. Puede ser que nos hayamos centrado tanto en el desarrollo de la app que hayamos olvidado que esta necesita una URL (una landing page, a ser mejor). Y, sobre todo, nada de flash.
5) ¿Tenemos una URL de soporte?
Necesitamos tener a punto una URL donde los usuarios puedan acceder para obtener soporte de la app por si esta no funciona, por si quieren enviar sugerencias, etc. Sin esta URL de soporte Apple no aceptará nuestra app. Puede ser un despiste muy normal que puede retrasar la salida de nuestra app.
6) ¿Tenemos los iconos en alta resolución?
El App Store pide el icono de la app a 1024×1024… puede ser que nos hayamos confundido y que hayamos diseñado el icono a una resolución mucho menor. Necesitaremos el icono a este tamaño para poder enviar la app a revisión.
7) ¿Tenemos descripción, título y etiquetas?
Si vamos a publicar una app para un cliente, tendremos que tener todo esto listo para poder enviar la app a revisión. Tendría que ser algo pensado, meditado, incluso escrito por alguien profesional que se dedique a descripciones de productos. De la descripción, el título y las etiquetas depende en buena parte el ASO de nuestra app.
8) ¿Y localicaciones?
¿Tenemos la app traducida a diferentes idiomas? Entonces las descripciones, títulos y etiquetas tendrán que estar también en esos diferentes idiomas. Además, cuantos más idiomas tengamos, más probabilidades de que los usuarios se descarguen la app.
9) ¿Política de privacidad?
Importante tener una publicada en nuestra propia web para que los usuarios puedan consultar desde la app o desde la web del App Store o Google Play. Habrá que redactarla con antelación, no el mismo día de publicar la app en cuestión. ¿Por qué? Porque es algo que tiene que redactar un profesional y no podemos esperar a hacerlo todo en el último momento.
10) ¿Capturas de pantalla a todas la resoluciones?
¡Quiero publicar la app ya! ¿Por qué Apple y Google me piden capturas de pantalla a tantos tamaños? ¿Cómo lo hago? Pues con el simulador, si no tienes dispositivos. Ala, a hacer capturas de pantalla del iPad retina, el iPad, el iPhone 4S, el iPhone 5, el iPhone 6, 6+… y en Android también, variedad de capturas. Otra opción es hacer las ‘capturas’ mediante Illustrator o Sketch o con el programa que hayamos elegido para hacer los prototipos y diseños de la app.
11) ¿La fecha de salida es realista?
¡El evento en el que se presentará la app es el 10 de octubre! Oh, y ahora estamos a 3 de octubre. ¡Qué prisa! Si Apple no acepta la app, el evento será un evento huérfano… Pues puede pasarte. Perfectamente. Tanto que Apple no acepte la app y tengas que volver a enviar una versión, como que de repente Apple tarde 10 días en revisar una app y no 7. Tienes que ser cauteloso y planear las cosas con antelación. Mejor enviar la app 1 mes antes del evento, por si las moscas.
12) ¿Y un plan B por si la app se retrasara?
En el caso de que vayas a contrareloj y decidas arriesgarte… ¿Has pensado en un plan B por si la app se retrasa? Del palo… una web promocional o decir que ahora está para Android y que en breve para iOS… Esto se ha hecho en más de un festival de música donde mientras se celebraba el festival los usuarios podían descargarse la app para Android, pero la de iOS no salió hasta que el festival terminó. En este caso, es importante ofrecer la información vía web para que todo el mundo pueda acceder y aprender de los errores.
