Has publicado una versión en el Apple Store con una feature espectacular. Tras un par de días en producción te das cuenta de que algo no va bien y que tienes malas reviews en el store. Mientras localizas el error vas perdiendo cada vez más usuarios... ¿te suena? No tienes una arquitectura limpia definida en tu proyecto, por lo que te cuesta localizar este fallo, un fallo que podría haberse previsto usando Unit Test, o haberlo detectado a tiempo usando un sistema de crash reporting. Tras unos años trabajando para startups móviles de diferentes partes del mundo como freelance, Roberto Garrido nos habla de su stack tecnológico preferido para intentar atajar este tipo de problemas.

1. 6 errores
a evitar si eres una
startup móvil
y quieres
evolucionar tu app
de forma rápida y segura
Roberto Garrido
robertogarrido.com
@che1404

2. • Freelance
• Desarrollo nativo iOS
• Trabajo remoto
• Equipos ágiles

3. ¿Qué os voy a contar?
1. No apostar por una arquitectura limpia y modular
2. No establecer tests unitarios como metodología de trabajo en tu
equipo
3. No realizar crash reporting
4. No analizar el uso que tus usuarios hacen de tu app (app analytics)
5. No escuchar a tus usuarios ni probar tu app con usuarios reales (beta
testing)
6. No entregar valor a tus usuarios de forma continua y planificada

4. 1. No apostar por una arquitectura limpia y
modular
• Publicas una feature que no tiene la adopción esperada
• Surge un problema en producción y empiezas a perder
usuarios
• Tienes una suite de apps que comparten funcionalidad y te
ves duplicando código y recursos

5. 1. No apostar por una arquitectura limpia y
modular
• La arquitectura son los cimientos de tu app
• Evolucionar nuestra app rápidamente ya sea añadiendo,
modificando o eliminando funcionalidad
• Reaccionar rápido frente a crashes y malas reviews
• Reduce costes y reutiliza recursos

6. 1. No apostar por una arquitectura limpia y
modular
• MVC: Model View Controller
• MVP: Model View Presenter
• MVVM: Model View ViewModel
• VIPER: View Interactor Presenter Entity Routing

7. 2. No establecer TDD como metodología de
trabajo
• Al añadir código siempre introduces alguna inestabilidad
• Probar todas y cada una tus funcionalidades manualmente

8. 2. No establecer TDD como metodología de
trabajo
• Comprobar automáticamente (mediante una suits de tests)
tras cada cambio introducido, que todo lo anterior funciona
• Detectar efectos secundarios antes de que lo hagan
nuestros usuarios

9. 2. No establecer TDD como metodología de
trabajo
• Quick: Librería de BDD
• Nimble: Librería de matchers
• Cuckoo: Framework de mocking

10. 3. No realizar crash reporting
• No hay peor sensación que los casques y salidas
inesperadas de una app
• Pérdida de usuarios
• Problemas legales…

11. 3. No realizar crash reporting
• Configurar alertas que te avisan cuando un error es muy
recurrente
• Monitorizar pequeños errores
• Reaccionamos pronto ante los errores más graves

12. 3. No realizar crash reporting

13. 4. No usar app analytics
• ¿Cuántos usuarios están usando la app?
• ¿Cuántas sesiones tiene al día?
• ¿Cuánto duran esas sesiones?
• ¿Están usando tu app de la forma en la que la habías
imaginado, o el flujo de navegación es diferente?
• ¿Cuántos usuarios están gastando dinero en tu app?
• ¿Cuánto dinero están gastando?

14. 4. No usar app analytics
• Para retener usuarios debes ofrecerles un producto que se
adapte a sus necesidades, tienes que medir
• Nos ofrecen estadísticas de cuánto, cómo, y durante
cuánto tiempo se está usando nuestra app
• Hacer hipótesis y A/B testing

15. 4. No usar app analytics

16. 5. No escuchar a tus usuarios
• Cuando tienes una base de usuarios grande y no quieres
sorpresas en producción
• Estás lanzando un MVP y quieres medir resultados primero
con un grupo reducido y controlado

17. 6. No entregar valor de forma continua
• Una nueva versión de iOS y tu código no es compatible
• Actualizaciones de software de terceros que rompen tus
funcionalidades
• Problemas ajenos a nuestro negocio
• Nuestros usuarios esperan que les entreguemos
actualizaciones
• Nuestro clientes quieren conocer el estado del proyecto

18. 6. No entregar valor de forma continua
• Sistemas de integración continua
• Compilan y lanzan los tests por nosotros
• Algunos prueba también las betas de iOS
• Nos permiten estar preparados para publicar, porque detectamos errores
de integración antes
• Automatización del despliegue
• Herramientas para automatizar tareas de release: compilación, testing,
tags y descripciones en el store, capturas de pantalla, etc.
• Nuestros usuarios perciben los cambios
• Nuestros clientes comprueban dónde va su inversión

19. 6. No entregar valor de forma continua

20. Atención startup: Sprint bi semanal
• ¿Para quién es este servicio?
• Tienes financiación ahora, pero incertidumbre en el futuro
• Tienes una app obsoleta, y necesitas actualizarla
• Tienes una app en producción y quieres evolucionarla
• Tu proyecto ha pasado por varias manos, y necesita
arquitectura
• Quieres empezar una app, pero no tienes muy claros aún
los requisitos

21. Atención startup: Sprint bi semanal
• ¿En qué consiste?
• Paquetes bisemanales de trabajo en remoto, hasta 40 horas de
disponibilidad
• Programación, consultoría, investigación, etc.
• ¿Cómo funciona?
• Seguimos metodología ágil en sprints de 2 semanas
• Los proyectos llave en mano hace tiempo que dejaron de funcionar
• Reunión inicial + trabajo + validación

22. Atención startup: Sprint bi semanal
Más info en robertogarrido.com/sprint-bi-semanal

23. ¡Gracias!
robertogarrido.com
@che1404
facebook.com/freelanceiosdev