desarrollo ios Bugfender

¿Cómo hacer un seguimiento de mi app en producción?

Existen multitud de tecnologías para hacer un seguimiento de una app cuando ya está en producción. La más común suele ser la integración de un framework de analíticas que nos va mostrando en un dashboard aquellos eventos que nosotros hayamos marcado como interesantes dentro de la app: tap de un botón, completar un proceso de compra in-app, completar un onboarding ,etc. Un ejemplo de framework de analytics es Firebase Analytics.

Otro tipo de tecnologías que nos permiten saber qué está pasando con nuestra app publicada son los crash reporting tools. En este caso, se trata de frameworks que nos muestran en un dashboard la información sobre los casques que están sufriendo nuestros usuarios. Entre estos frameworks destaca Crashlytics (que será en breve integrado en las herramientas de Firebase), que nos muestra un listado de casques filtrados por versión de app, y ordenados por el número de ocurrencias de cada uno, llegando a indicarnos incluso la línea de código donde se están produciendo.

Herramientas de remote logging

Pero hay ocasiones en las que este tipo de seguimiento no es suficiente. Llevo trabajando durante los últimos dos meses en un prototipo para un cliente de USA, que utiliza de forma asidua el sensor GPS del iPhone, así como el sensor de actividad a través del framework CoreMotion de Apple. (CoreMotion es la tecnología que Apple ofrece para procesamiento de datos de acelerómetro, giroscopio, podómetro, y eventos sensibles al contexto del usuario)

En concreto, la app tiene que actuar cuando ocurre una combinación de cambio de actividad del usuario y su posición GPS. Ocurre que estos dos sensores no se pueden emular en el simulador del iPhone, y por tanto no queda más remedio que salir a la calle, si quiero probar estos casos de uso en un escenario real.

Evidentemente, cuando estoy en la calle no puedo debuggear “paso a paso” la aplicación para saber qué es lo que pasa realmente, por lo que para analizar bien todos los casos he decidido integrar una herramienta de remote logging.

Estas herramientas te permiten enviar mensajes a un dashboard en tiempo “casi” real, para su posterior análisis. De forma que lo que hago es salir a la calle y realizar todos los casos de uso que permite la aplicación. Si algo fue mal, vuelvo a la ofi, y me pongo a analizar los logs, ver lo que ha pasado, e intentar subsanar el problema.

Herramienta de seguimiento con remote logging: Bugfender

ios developer Bugfender dashboard

Dashboard de Bugfender

Durante el desarrollo del prototipo consideré varias alternativas al cloud logging, entre ellas JustLog, del equipo de JustEat, o SwiftyBeaver. Bugfender fue mi decisión final, sobre todo debido a su facilidad de integración. Con tan sólo integrar el SDK en el proyecto via Cocoapods, e introduciendo el API key al inicializar la app,  ya podíamos empezar a loggear mensajes en la nube.

Los mensajes se envían de forma casi simultánea, pues tan sólo tardan unos 20 segundos en aparecer en el dashboard. Además, éstos aparecen filtrados por sesión. Entendiendo por sesión la ejecución de una versión de la app, con un ID de instalación determinado, en un dispositivo concreto.

Respecto al precio, con la capa “free” tienes derecho a subir una app, usar un sólo usuario, y tener una retención de logs de 24 horas. Suficiente para hacer tus primeras pruebas debuggeando fuera de la oficina cuando es necesario. Si tu prototipo ya está lo suficientemente evolucionado, tienes un grupo de usuarios de prueba, y necesitas una retención de logs de más de una semana, tienes que pasar al plan “startup”, al “business”, o al “premium”.

Conclusión

Que conste que no estoy cobrando ni un duro por la redacción de este artículo sobre Bugfender. Simplemente quería contarte que es una herramienta muy útil para hacer un seguimiento “outdoors” determinado tipo de apps que usan sensores, y que por tanto son muy incómodas de testar en la oficina. Lo que más me llamó la atención fue su facilidad de integración: sólo la he integrado en iOS, pero me consta que en Android será igual de sencillo. También considero que el precio de la capa “startup” (25EUR/mes) es muy asequible para probar tu prototipo en fases tempranas.

¿Y tú? ¿Tienes una app que usa GPS o sensores de movimiento? ¿Cómo la debuggeas? ¡Cuéntamelo en los comentarios!

 

 

No hay comentarios

Deja un comentario