¿Cómo elegir la mejor arquitectura para una aplicación móvil iOS?

A la hora de empezar un nuevo reto como es construir una aplicación móvil, uno de los temas estrella es siempre decidir cuál es la mejor arquitectura en que se debe basar. Este debate puede llegar a niveles insospechados de rivalidad de opiniones, casi parecido a cualquier cafetería después de un Real Madrid vs Barcelona, pero que debería basarse en varios criterios objetivos en los que los fanatismos quedan descartados.

Elegir la mejor arquitectura para una aplicación móvil iOS

Centrándonos en el mundo Apple, por mucho que algunos especialistas digan que existen arquitecturas “nativa “, no hay un documento claro en que la propia empresa recomiende o sugiera una arquitectura recomendada. Históricamente cuando hablamos de aplicaciones basadas en UIKIT, el estándar gráfico en la mayoría de las aplicaciones actuales, todos los ejemplos oficiales se basan en una arquitectura MVC simple. Y quizás esto ha llevado a la confusión de que dicha arquitectura fuese considerada el estándar a la hora de construir cualquier aplicación iOS.

El primer criterio que se debería utilizar a la hora de elegir debería ser la dimensión del proyecto e incluso del equipo. Está claro que en los ejemplos de Apple donde se muestran pequeñas aplicaciones, que podrían ser incluso diseñadas por una sola persona, no habría problema en utilizar MVC. El problema surge cuando nos tenemos que plantear un equipo profesional, con una aplicación con muchos módulos funcionales interconectados, donde la estructura cobra una mayor relevancia. Es aquí donde los principios SOLID deben ser tomados como referencia a la hora de plantear la arquitectura.

Sin entrar mucho a definir ejemplos técnicos, en una arquitectura MVC es muy frecuente que no se cumplan varios de ellos. Ya que las clases ViewController suelen ser utilizadas para todo: controlar la lógica de presentación, gestionar la lógica de negocio, llamar a los servicios implicados y tratar la respuesta… Es aquí donde dicho tipo de clases no cumplen el principio de tener una única responsabilidad o rol específico. Y es donde surgen clases inmanejables, de miles de líneas de código que hacen que mantenerlas sea un auténtico trabajo de “ñapa” tras “ñapa” , donde los conflictos hacen que tu vida como desarrollador sea un verdadero infierno.

Este problema conocido generalmente como “Massive View Controllers”, es donde nos lleva a tener claro que esa arquitectura MVC no es válida para aplicaciones de gran tamaño y con un grupo de desarrolladores extenso.

Pero… ¿qué otros factores tenemos que considerar a la hora de elegir una buena arquitectura?

En mi opinión existen una serie de puntos que deben ser considerados:

• Debe ser fácil de mantener. De nada sirve una arquitectura que no sea mantenible con el paso del tiempo y que no permite añadir fácilmente nuevas funcionalidades.
• Se debe determinar un estándar para todos los integrantes de tu equipo técnico. Para que tus desarrolladores se formen en ella y sea fácil el cambiar de proyecto entre clientes.
• Debe ser fácil testear la lógica de negocio. Esta es la parte fundamental de la aplicación en la que se debe asegurar una robustez en las pruebas.
• Separar la responsabilidad de tus clases. Esta es la forma sin duda de que el trabajo en equipo llegue a buen puerto con el menor número de conflictos. Si queremos evolucionar una funcionalidad y al tener separadas las capas, esto permite por ejemplo modificar fácilmente la parte visual sin tener que tocar una línea de la capa de negocio.

Teniendo en cuenta todos estos puntos es donde surgen varias candidatas que compiten por ser la ganadora de la batalla de arquitecturas. Arquitecturas que en sus nombres generalmente indican que capas van a componerla: VIPER, MVVM, MVP , VIP Clean , Modular Architecture…

Daría para varios artículos escribir las ventajas y desventajas que se esconden bajo estos nombres. Y cuentan en sus filas tantos defensores como enemigos.

Cada una de ellas interpreta la mejor forma de aplicar los principios anteriormente comentados a su manera Existiendo incluso evoluciones dentro de ellas mismas, interpretaciones que hacen que cada arquitecto las modifique con su propia visión.

Quizás la más extendida de ellas sea VIPER, arquitectura que usamos en nuestra casa para la mayoría de los proyectos. Tiene la ventaja de que simplifica bastante la separación de capas, hace muy escalable el código y divide los componentes de la aplicación en función de su rol. Pero quizás se vuelva en contra para usarla en proyectos pequeños que no tengan un futuro de estabilidad, e incluso desarrollados por una o dos personas. Donde plantear dicha arquitectura quizás sea gastar más tiempo que un MVC simple al uso.

VIPER no es el final del camino. Como intento explicar a lo largo de este artículo NO existe una arquitectura que sea la respuesta en todas las situaciones.

Pero es que además existe un último factor importante proporcionado recientemente por Apple: SwiftUI.

Esta tecnología no solo comprende una nueva forma de diseñar pantallas, es además una revolución a la hora de plantear una aplicación en iOS. Ya que plantea una programación reactiva que en muchos casos nada tiene que ver con una programación funcional al uso.

Y es que el propio SwiftUI, debe ser utilizado con cautela. Ya que ha ido creciendo y madurando con las últimas versiones del sistema operativo donde fue creciendo. Y era bastante inmaduro e incompleto en sus primeras entregas. Con lo que no recomiendo usarlo en proyectos que tengan que dar soporte a versiones antiguas del sistema operativo. Es un auténtico quebradero de cabeza.

¿Y qué arquitectura se debe usar en SwiftUI?

Pues es la pregunta del millón de dólares, que actualmente se plantean miles de desarrolladores. Con el nuevo paradigma no hay una respuesta clara y aunque los ejemplos de Apple indican que un MVVM es la arquitectura más lógica. Alternativas como Composable están surgiendo con gran fuerza como alternativas.

Pero sinceramente, esta lucha no ha hecho nada más que comenzar.