¿Por qué lanzamos Swift y no SwiftUI?

En todas las WWDC celebradas desde 2019 se ha apostado cada vez más por SwiftUI, y cada vez que empezamos una nueva aplicación nos reunimos en equipo para plantearnos la misma pregunta: ¿Ya se ha ganado un hueco en nuestras aplicaciones? Hasta ahora, la respuesta ha sido «no» en lo que respecta a los aspectos importantes, y probablemente «sí» en lo que respecta a los que no lo son.

Esto no es un juicio sobre SwiftUI en general. Hay muchos equipos que lanzan aplicaciones excelentes con este marco. Es una descripción de dónde encaja en nuestro caso: un pequeño estudio que mantiene varias aplicaciones iPhone y iPad a la vez, sin margen para sorpresas en ninguna de ellas.

Lo que funciona

SwiftUI es realmente genial para pantallas de configuración estáticas, diseños de formularios y cualquier situación en la que el árbol de vistas sea pequeño y el flujo de datos sea unidireccional. Nosotros lo utilizamos. También lo usamos para obtener vistas previas mientras diseñamos: el ciclo de iteración es más rápido que el de UIKit.

En la práctica, esto significa que la pantalla en la que se seleccionan unidades o se exportan datos suele estar realizada con SwiftUI, integrada en una aplicación cuyas pantallas principales están creadas con UIKit. Ambas coexisten sin apenas problemas, y combinarlas nos permite aprovechar los puntos fuertes de cada una en lugar de tener que basar toda la aplicación en un único enfoque.

Lo que no (para nosotros)

En cuanto una pantalla necesita gestos personalizados, listas que exigen un alto rendimiento, un estado de navegación complejo o una sincronización precisa de las animaciones, volvemos a recurrir a UIKit. La razón no es una moda pasajera, sino el tipo de errores que nos encontramos cuando no lo hacemos. SwiftUI ha mejorado considerablemente en sus últimas versiones, pero sigue sorprendiéndonos en tiempo de ejecución de formas en las que UIKit rara vez lo hace.

Los ejemplos concretos ayudan. Una aplicación para aprender a teclear necesita que cada pulsación genere el carácter correcto sin retrasos visibles y que la pantalla siga el ritmo de los dedos del usuario. Un historial extenso de entradas registradas en un gestor de tareas debe desplazarse con fluidez en un teléfono antiguo. Una agenda con función de arrastrar y soltar necesita gestos que no entren en conflicto con los propios del sistema. Ese es el tipo de pantallas en las que hemos encontrado que UIKit es más predecible.

Las ventajas y desventajas

Seguir utilizando UIKit tiene su precio. Implica más código para la misma pantalla, y significa que cualquiera que se incorpore al proyecto tiene que sentirse cómodo con un marco de trabajo más antiguo que los tutoriales suelen omitir cada vez más. Algunas nuevas funciones del sistema llegan primero a SwiftUI, y adoptarlas desde UIKit requiere un trabajo adicional de adaptación. También debemos ser sinceros y reconocer que parte de nuestra cautela se debe a la familiaridad: conocer a fondo un marco de trabajo tiene su valor, pero también puede convertirse en una excusa.

También hay una cuestión pendiente. Nuestras aplicaciones iPhone y iPad ya funcionan en los Mac con Apple Silicon, y tenemos previsto desarrollar aplicaciones nativas para Mac. Si SwiftUI facilita de forma significativa el uso compartido del código de interfaz entre esas plataformas, el cálculo podría cambiar.

En qué nos equivocamos

En una ocasión utilizamos SwiftUI para una pantalla que, sobre el papel, parecía sencilla, pero que resultó no serlo: una lista con acciones de deslizamiento personalizadas y un estado que cambiaba al desplazarse. Funcionaba bien en las vistas previas, pero de forma extraña en los dispositivos reales. Reconstruirla en UIKit nos llevó más tiempo del que nos habría llevado empezar desde cero con ese framework. Ahora lo decidimos pantalla por pantalla, desde el principio, en función de lo que la pantalla tenga que hacer realmente.

Esa es la única prueba de verdad: ¿Nos sorprenderá esto en la producción? En la mayoría de los proyectos que desarrollamos, la respuesta descarta el uso de SwiftUI como base. Volveremos a planteárnoslo el año que viene.