El pasado lunes 3 de Junio durante la Keynote inicial de la WWDC 2019 Apple presentaba SwiftUI. La de este año ha sido una World Wide Developers Conference cargada de notícias importantes. No se anunciaban cambios tan importantes en cuanto al desarrollo de software desde la presentación de Swift en 2014.

Con esta novedad Apple pretende seguir el camino implantado por otros frameworks como Flutter y React y facilitar la ardua tarea que hasta ahora ha significado el desarrollo gráfico en los sistemas Apple. SwiftUI será el nuevo framework multiplataforma - MacOS, IPadOS, iOS y watchOS -  de desarrollo de interfaces gráficas que a partir de iOS13 empezará a hacerse hueco y paulatinamente desplazando a UIKit.

Este anuncio significa un punto de inflexión con respecto a lo que hasta ahora habíamos conocido. Apple permitirá implementar sus entornos gráficos de modo declarativo y no imperativo. ¿Significa esto que desaparece UIKit? La respuesta es simple y llanamente NO. De echo, la especificación actual - que es posible probar con la beta de MacOS Catalina - es una capa implementada sobre UIKit. Aunque se espera que su implantación vaya progresivamente dominando todo el espectro de desarrollo de interfaces en sistemas Apple hasta convertirse en el modelo standard.

Hasta la fecha, UIKit nos obligaba a escribir ingentes cantidades de código para implementar nuestras pantallas: primero debíamos crear nuestra clase heredada de UIView o bien usar uno de los objetos de la librería, configurarla, ubicarla jerárquicamente en la estructura de la vista y finalmente mediante reglas como Autolayout darle acomodo de forma responsiva.

Como alternativa a esto encontrábamos el InterfaceBuilder, que nos permitía crear las inteficies de forma gráfica para posteriormente asignar unos eventos denominados IBActions e IBOutlets que nos permitían conectar nuestra vista con nuestro controlador e implementar ahí la lógica mediante la cual actualizar los elementos gráficos. Pero este sistema no ha acabado de tener una gran acogida entre los desarrolladores, entre otras cosas por su ineficiencia a la hora de implementar interfaces complejas.

 

¿Que es en esencia SwiftUI?

SwiftUI es un Framework para implementación de vistas, de tipo declarativo. Esto significa a la postre, que la estructura del código describe cómo es la vista e implementa dicha vista. Algo similar, manteniendo las distancias, a lo que encontramos, por ejemplo, en HTML a nivel estructural. 

Cada objeto implementado por SwiftUI es un trozo de vista. Dicha vista esta compuesta a su vez por otras vistas de forma modular e iterativa, de forma que una vista puede contener otras vistas que hayamos definido y así hasta el infinito, como si de una muñeca rusa se tratase.

 

 

 

Cada una de las declaraciones de una vista es un contenedor estanco, es decir una caja que devuelve una vista y que a su vez esta formada por otras cajas y así sucesivamente conformando la jerarquía de la vista.

Los elementos que componen una vista pueden ser modificados una vez ya definidos mediante unos métodos denominados modifiers. Podríamos entender los modifiers como funciones que devuelven una vista resultante de forma que podemos encadenar modifiers hasta obtener una vista final resultante acorde con lo esperado. Cambiamos: color, posición, tamaño e incluso implementamos movimientos o comportamientos con los modifiers.

 

Los elementos que componen una vista en SwiftUI son structs - almacenados en la memoria y pasados por valor - que implementan el protocolo View .

Los objetos que implementan dicho protocolo únicamente requieren una variable : la variable body, que contiene la vista que estamos implementando. Dicha variable es una propiedad computada y es así porque a diferencia de lo ocurrido hasta ahora, un objeto View se renderiza de forma automática cada vez que modificamos su estado.

 

 

Con SwiftUI las dependencias de las vistas - es deicir datos mediante los cuales rellenaremos nuestras vistas - son definidos en la propia vista. De este modo, cuando uno de estos datos cambia, el entorno sabe que el renderizado de la vista debe ser recalculado acorde con el nuevo valor, de modo que recalcula la propiedad computada body para dar un resultado actualizado.

Los estados de una vista se pueden clasificar segun los ejes lectura/lectura+escritura y fuente de certeza/valor derivado. Se clasifican en 4 tipos: 

• constantes - Solo lectura. Fuente de certeza.

• propiedades simples - Solo lectura. Valor derivado.

• @State - Lectura y escritura. Fuente de certeza.

• @Bindings - Lectura y escritura. Valor derivado.

En realidad es SwifUI quien se encarga de mantener la consistencia entre los datos y el estado de la vista. Ya no hay que estar seteando eventos para actualizar el UIView sino que siguiendo una suerte de programación reactiva, le indicamos mediante objetos que implementan el protocolo identifable quien es el modelo con el que se debe de actualizar y automáticamente al modificar el modelo, la vista es nuevamente renderizada.

 

Ver lo que diseñamos

Además SwiftUI nos provee de unas herramientas de diseño, que nos muestran el resultado del código que estamos construyendo de forma casi instantánea y sin tener que usar el emulador. No solo eso, sino que nos permite también hacer cambios directamente sobre el diseño representado mediante un menú contextual y automáticamente estos cambios se ven reflejados en el código. Algo que nada tiene que ver con el Interface Builder.

 

 

Incluso podemos hacer algo parecido desde un playGround importando la librería PlaygroundSupport:

 

Todas estas mejoras y muchas más que estan por llegar son las que nos va a aportar este nuevo framework disponible a partir del próximo otoño. Desde Iflet.tech las seguiremos con atención.