SwiftUI: historia y primeros pasos para hacer tu propia interfaz

Si hay que elegir un momento especial o un lanzamiento reseñable en la última WWDC, ese es, sin duda, SwiftUI. Ya os hablamos de él hace poco y cómo cambiará la forma en que los desarrolladores y diseñadores hacemos las apps. Pero hoy queremos hablaros del proyecto en sí, de dónde surge, por qué solo funciona en iOS 13 en adelante y una breve introducción a su desarrollo. Además os ofrecemos en exclusiva una pequeña y simple introducción para que veáis lo fácil y simple que es crear interfaces con esta nueva tecnología creada por Apple.

SwiftUI, un proyecto con 3 años de vida

Creo que podemos ponernos serios al decir que un proyecto como SwiftUI, que funciona en todos los sistemas de Apple como macOS, tvOS, watchOS, iPadOS y iOS, no es algo que hacen 3 colegas en el Apple Park en un rato, en plan: "¡oh mira, Google ha lanzado Jetpack Compose, vamos a copiarlo!". Crear una librería como SwiftUI, tan integrada en el propio lenguaje y que incluso ha obligado a este a evolucionar e incluir elementos nuevos para poder funcionar, no es algo de unos días de picar y ya. Es un proyecto de años, como lo fue antes de SwiftUI el mencionado Jetpack Compose (lanzado en mayo en la Google I/O), Flutter o React Native.

Crear una librería de interfaz competente como Flutter, React Native, Jetpack Compose o SwiftUI y que funcione tan bien como cualquiera de estas, es trabajo de años de decenas o cientos de ingenieros en un equipo de trabajo e incluso varios equipos diferentes.

En conversaciones con algunos ingenieros tras el proyecto en Apple, estos han confirmado que llevan trabajando en SwiftUI aproximadamente unos 4 años. Por lo que he podido leer en los últimos días, parece que la fuente de todo es la tecnología React Native de Facebook. Esta forma de crear interfaces de manera declarativa, que apareció en marzo de 2015, al momento llamó la atención de Apple. Principalmente el hecho de cómo Facebook había resuelto técnicamente la construcción de UIs de manera más cómoda e intuitiva. Viendo el éxito que tenía en la comunidad de desarrolladores, se pensó que podría aplicarse ese concepto dentro del lenguaje Swift para llevar algo tan disruptivo también a los entornos de Apple.

Así que un equipo en Cupertino empezó a explorar este concepto pero aplicado a Swift y a cómo funciona. Con conceptos como la orientación a protocolos y los tipos por valor, dos de las características que mejor definen Swift. Y lo probaron con el dispositivo menos exigente de todos los de Apple, que fue aquel donde surgió la semilla de SwiftUI: en watchOS. Si lo analizamos, el smartwatch de Apple es el menos exigente en cuanto a uso de constraints y elementos, y era el sistema ideal para empezar a prototipar esa nueva forma de trabajo.

Dave Abrahams durante una de las ponencias de SwiftUI en esta WWDC.

Durante el primer año aproximadamente, tal vez un poco más, este equipo consiguió resultados bastante interesantes y eso llamó la atención al resto de equipos del Mac o de iOS. Básicamente, al ver la capacidad que tenía este framework y lo bien planteado que estaba, quisieron que este fuera a mayores. Y lo que en principio iba a ser una forma declarativa para el Apple Watch, se convirtió con ayuda del resto de equipos en una librería para todos los sistemas de Apple. Algunos de los ingenieros más reputados en Cupertino como Dave Abrahams (arquitecto de C++ antes de fichar por Apple), Luca Bernardi, John Harper o Nate Cook están involucrados en mayor o menor medida en el desarrollo de SwiftUI.

SwiftUI, no antes de Swift 5.1

Cuando Apple lanzó Swift 5 os hablamos aquí de un concepto fundamental que permitía al lenguaje llegar mucho más allá: la estabilidad binaria.

Un lenguaje de programación en sus inicios, suele tener un problema de base: la estabilidad del código binario. Un lenguaje como Swift tiene una parte esencial para él mismo que es su librería estándar. En ella están los componentes que usamos para trabajar, como la mayoría de tipos del sistema, APIs y partes esenciales que sin ser el lenguaje en sí y su estructura fundamental, son librerías y tipos de datos que forman parte imprescindible del mismo.

En Applesfera

Craig Federighi cuenta detalles sobre iPadOS, SwiftUI y más en una nueva entrevista

El problema, es que hasta Swift 5, solo la librería estándar compilada en una versión concreta era capaz de ejecutar código binario de esa misma versión. Si cambiamos la versión, la forma de conectar como código binario compilado no funcionaba. Por eso hasta Swift 5, cualquier programa en Swift debía incluir la librería del lenguaje en sus recursos. Si teníamos 30 apps en Swift, pues 30 veces la librería en diferentes versiones, en cada app.

Estabilidad ABI de la librería estándar en Swift 5

Con Swift 5 esto se arregló, y ahora Swift 5.1 (versión que acompaña a Xcode 11 lanzado en la WWDC, que será la versión final para las nuevas versiones mayores de todos los sistemas de Apple) ha dado el paso definitivo: la estabilidad de módulos. La forma en la que una librería (o framework) es capaz de compilarse de forma binaria, cargarse en el sistema operativo y permitir que cualquier versión a partir de esta 5.1 de Swift pueda conectar y entenderse a nivel binario con cualquier app que quiera usarla.

La estabilidad de módulos de Swift 5.1

¿Qué permite esto? Que Apple pueda poner librerías nativas hechas en Swift cargadas en el sistema operativo, que cualquier app las use, pero que no necesite incluirlas dentro de ella. Este es el motivo principal por el que las apps a partir de iOS 13 van a ocupar mucho menos, pues una gran carga de librerías básicas de cualquier app se estaban copiando tal cual en cada app que las usaba. Y esto hacía que ocuparan demasiado.

¿Por qué cuento todo esto? No solo para explicaros por qué ahora las apps van a ocupar mucho menos en iOS 13 (aparte de otros factores como compresión de recursos gráficos y demás). Porque precisamente esto que os contamos es lo que hace que las apps diseñadas con SwiftUI solo puedan ejecutarse en iOS 13, iPadOS 13, macOS 10.15, watchOS 6 y tvOS 13: porque la librería está cargada en el sistema operativo gracias a la estabilidad de módulos.

SwiftUI funciona solo en las últimas versiones de los sistemas de Apple porque está cargado en el sistema operativo. Para que SwiftUI funcionara en versiones anteriores, habría que copiar toda la librería y sus dependencias en cada app que lo usara, lo cual haría que ocuparan mucho más.

De hecho, este año Apple ha aprovechado para liberar un buen número de librerías hechas específicamente en Swift, que por primera vez pueden ir en el sistema operativo, como la citada SwiftUI, RealityKit para realidad aumentada o Combine para gestión asíncrona de eventos que trabaja mano con mano con SwiftUI.

¿Y cómo se hace una app con SwiftUI?

Básicamente, todo radica en un elemento clave: la vista. Esa vísta ha de devolver un Body (un cuerpo), donde esté el contenido. Un contenido que debe tener un contenedor de mayor nivel (solo uno) que puede ser desde un elemento aislado como un texto, hasta una construcción anidada de varios elementos unos dentro de otros. Pero solo una vista en el mayor nivel.

Podemos poner una barra de navegación (que sería el elemento de mayor nivel que devuelve el cuerpo), dentro una vista apilada vertical, dentro un botón y en el botón un texto y una imagen, por ejemplo. Dentro de una vista, además, podemos devolver otras vistas que hayamos hecho en otras estructuras con más elementos, y así crear una jerarquía de estos más compleja pero organizada por otro lado.

Un ejemplo de tabla con celdas que a su vez hacen scroll horizontal en SwiftUI

Como elementos de mayor nivel del sistema podemos devolver vistas de navegación, listas, vistas apiladas, formularios, vistas de scroll... en la composición de estos y el resto de elementos estará la forma de componer las interfaces. Cualquier vista puede estar en el mayor nivel o ser parte del anidado. Una estructura muy parecida a una página web, básicamente.

¿Y los datos? Podemos pasar datos entre diferentes vistas que usemos, usar enumeraciones de datos dentro de la propia estructura o crear fuentes de datos síncronas que nos proporcionen objetos como datos dinámicos. Incluso datos asíncronos que una vez recuperados provoquen eventos en la interfaz para que se muestren. También podemos darle estado a alguna propiedad y cada vez que esta cambie, la vista en pantalla será redibujada.

Otro ejemplo en SwiftUI con un campo multilínea

Si queréis ver un pequeño tutorial sobre cómo componer un formulario con SwiftUI, os dejo aquí un vídeo que he colgado en Youtube, dentro de una sección de Apple Coding que llamó Snippets, donde veréis de una forma sencilla y rápida la forma de construir una vista simple y cómo podemos ver en tiempo real el resultado.

¿Por qué SwiftUI?

Es una realidad que con la tecnología actual de hacer y diseñar apps en Apple, a los diseñadores se les hace bola entender cómo la interfaz que podamos dibujar conecta con el código. Y a los programadores se nos antoja una pereza indescriptible el tener que replicar las ideas de un diseñador que, al no ceñirse a cómo se construyen las interfaces en Apple complica en exceso nuestro trabajo. Todo son problemas.

No engañamos a nadie si decimos que la tecnología tras el desarrollo actual de apps para Apple tiene más de 40 años (viene de los años 70) y se ha quedado un poco desfasada.

SwiftUI se acerca a un concepto más similar a la web y su diseño adaptativo (como ya hiciera el precursor React Native) para que sea más fácil de entender y diseñar por gente que se dedique puramente al diseño. Permite ver de un simple vistazo cómo va a quedar la interfaz y entender de dónde viene cada elemento y está conectado. Es más fácil de mantener y dada su sencilla estructura, será muy fácil que herramientas de diseño como Sketch o Adobe XD puedan crear "generadores" de código que traduzcan un diseño directamente a código para pasar a un desarrollador.

Sin duda se ha iniciado una nueva Era en el desarrollo de apps para sistemas Apple y es muy emocionante. Y solo hemos empezado a andar el camino... un camino donde apuesto que Apple creará cada vez más componentes (e incluso terceros desarrolladores) que enriquecerán al final la experiencia de los usuarios. Todos ganamos. Si quieres empezar a probar solo necesitas un Mac y bajarte Xcode 11. Si quieres verlo en forma previa, sí necesitarás instalar las betas de macOS Catalina y de cualquier dispositivo que tengas.

Desde este pequeño rincón, felicitamos a todo el equipo detrás de este desarrollo. Bravo.