Actualmente hay infinidad de opiniones respecto al uso de librerías externas para proyectos iOS, podemos encontrar un gran número de desarrolladores promoviendo el uso de estas casi para cualquier tipo de solución, desde soluciones de navegación y vistas hasta tratamientos de datos internos (almacenamiento y procesamiento).
Desde que empecé a desarrollar iOS pude notar como hay una clara tendencia en muchas guías y en muchos desarrolladores por reflejar lo «básico» que es el desarrollo con librerías de terceros, sin embargo, cuando un desarrollador no experimentado está iniciando con estas opciones omite información que a mi modo de ver es relevante al iniciar un proyecto iOS, llegando incluso al punto de plagarla de librerías externas sin necesidad.
Por lo anterior, les voy a presentar algunos cuestionamientos que debemos hacernos al momento de usar librerías externas haciendo un mejor uso de estas.
¿Lo puedo hacer de forma nativa?
Apple ha dispuesto librerías nativas suficientes para hacer básicamente todas las aplicaciones actualmente conocidas, sin embargo, algunas de estas pueden considerarse de difícil uso para ciertos desarrolladores, y es aquí donde las librerías externas entran a jugar un papel activo; muchas de estas librerías pasan a ser en ocasiones accesos directos a funciones existentes con otros nombres.
¿A qué me refiero? vamos a verlo con un ejemplo: Alamofire, es una popular librería de Networking que agrupa diferentes funciones para realizar llamados REST además de ofrecer diferentes opciones de parsing, reachability, encoding, decoding, entre otros. Esto está bien, para proyectos que requieran un gran número de requests y acciones de red puede funcionar de maravilla facilitando enormemente el desarollo, pero ahí es donde entra nuestro cuestionamiento, Alamofire en el fondo toma las mismas funciones que Apple provee para hacer requests y las presenta bajo una nueva firma y con todos los argumentos requeridos de antemano (básicamente un wrapper), y es esto lo que responde nuestra primera pregunta, SÍ, podríamos hacer todo lo que Alamofire hace de forma nativa, ya que al ellos usar en el fondo las herramientas nativas implica que nosotros también podemos usarlas sin ningún inconveniente y a partir de esto formularnos el segundo cuestionamiento.
¿De verdad lo necesito?
Ya vimos que una librería de terceros suele ser una forma mas fácil de acceder a herramientas nativas existentes, pero eso no necesariamente implica que para nuestro proyecto una librería sea la mejor opción; he visto casos donde se ha esperado que usando librerías externas se solucionen problemas que en el fondo son muy triviales, y la mayoría de casos pasan por desconocer puntos básicos de desarrollo en iOS, esto es, en términos de ciclos de vida, tipos de datos, funciones y componentes internos, entre otros.
Retomando el ejemplo anterior de Alamofire, si estuviéramos construyendo una aplicación en la cual sólo necesito hacer un único llamado REST – GET – para llenar datos, sería inconcebible pensar en el uso de esta librería ya que estaría aportando un sinnumero de funciones que no se van a utilizar y se relegaría el llamado GET a una sola función de Alamofire, la cual puede ser simplemente reemplazada por su método nativo con URLSession.
Es así entonces como se necesita tener conciencia del propósito real de la librería y pensar ¿qué tanto le aporta al desarrollo y qué contras puede traer? (a nivel de peso adicional por ejemplo).
¿Es esencial para el buen funcionamiento de mi aplicación?
En este punto es necesario evaluar el aporte real de la librería y analizar si hay mejores opciones a la elegida. Pueden haber casos donde sí o sí la aplicación requiera tener librerías externas bien sea por una necesidad puntual del negocio, porque el conocimiento técnico del desarrollador no alcanza a solucionar el problema de forma nativa o, porque el costo de la implementación nativa puede ser mayor que la de simplemente consumir una librería ya existente.
¿Qué librería usar?
Si la decisión final es el uso de una librería externa, es necesario no sólo buscar la que solucione determinado problema si no, la que lo solucione de la mejor manera posible.
Actualmente existen muchas librerías que solucionan infinidad de problemas a nivel funcional, sin embargo, se deben considerar algunos puntos al momento de elegirla:
- Mantenibilidad: Esto es algo fundamental en el desarrollo de software donde este se convierte en algo mutable, y encontrar una librería que funcione a la fecha no garantiza que lo haga en uno o dos años; esto puede acarrear serias consecuencias como son reprocesos, refactor, cambio de librerías y ajustes a nivel de código; lo cual se evita fácilmente al buscar librerías que estén soportadas en una comunidad, que su proceso de actualización sea evidenciable y donde sus últimas actualizaciones no daten de un poco mas de 3 meses, por decir una fecha.
- Rendimiento: Este es un punto bastante complicado sobre todo para quienes apenas inician con el desarrollo iOS, ya que por lo general se tiende a omitir el cómo está construida la librería y sólo se mira que esta solucione determinado problema.
Es bastante recomendable analizar cómo está construida internamente, en primer lugar para aprender, en segundo para verificar que la librería no esté haciendo algo que uno mismo pueda desarrollar en pocos pasos de manera nativa, y por último, para evitar crashes, errores de threading, memoria o manejo incorrecto de datos y nulos. - Documentación: Este es quizá por mucho el punto más complicado de cumplir, y es que no es tan habitual como se esperaría encontrar documentación completa para librerías externas, ya que para los autores de estas, se vuelve un proceso que sólo con el tiempo y diversas iteraciones se logra concretar.
Lo recomendable aquí es entonces, fijarse únicamente en aquellas librerías que además del proceso de instalación, detallen versionamiento, comunidad, guías de uso, y de ser posible si tienen ejemplos aplicados en otros proyectos; todo esto para que el desarrollador pueda hacer uso de esta de la mejor forma posible.
Conclusiones
- Ten precaución con el uso de las librerías externas, su uso no es malo ni prohibido pero es algo que debe hacerse a conciencia.
- Apple ha dispuesto las herramientas nativas suficientes para crear apps robustas; evalúa previamente si lo que se está desarrollando se puede soportar enteramente con dichas herramientas.
- Evita plagar de librerías una aplicación, considera que esto aporta procesamiento y funciones adicionales; de esta manera, una aplicación que normalmente pese 3Mb se convierte en una de 10Mb o más, dejando cientos de lineas de código muerto.
- Al momento de elegir una librería se deben revisar la documentación, mantenibilidad y rendimiento de esta para evitar futuros dolores de cabeza.
