Últimos articulos

SwiftUI lleva años apoyándose en una idea muy potente: describir interfaces mediante pequeños bloques declarativos. Escribimos VStack, List, ToolbarItem, CommandMenu o Tab, y dentro de sus closures vamos declarando el contenido que queremos mostrar. Esa sintaxis parece natural, pero detrás hay una pieza del lenguaje Swift que hace mucho trabajo por nosotros: los result builders.

Durante mucho tiempo, el nombre más visible dentro de SwiftUI ha sido @ViewBuilder. Lo hemos usado para crear vistas compuestas, propiedades calculadas, inicializadores de componentes reutilizables y bloques de código que devuelven some View. Sin embargo, SwiftUI ya no se limita a construir simples vistas. También construye barras de herramientas, comandos de menú, pestañas, escenas, animaciones y otros tipos de contenido declarativo.

SwiftUI lleva años empujándonos hacia una idea muy concreta: la interfaz debe ser una consecuencia directa del estado. Si hay datos, se muestra una vista. Si esos datos desaparecen, la vista también desaparece. Es una idea sencilla que cuando se aplica bien elimina mucha lógica accidental y hace que la navegación de la aplicación sea predecible.

Hasta ahora, esa filosofía estaba muy clara en APIs como sheet(item:), popover(item:) o navigationDestination(item:). En todas ellas, la presentación depende de un valor opcional. Cuando el valor pasa a ser distinto de nil, SwiftUI presenta el contenido. Cuando la presentación se cierra, el valor vuelve a nil.

Con las novedades presentadas por Apple en la WWDC de 2026 en torno a la Inteligencia Artificial y el Machine Learning, ha habido bastante lío en la comunidad, tanto entre desarrolladores como entre usuarios civiles. Entre el naming —que si Foundation Models, que si SiriAI— y la Unión Europea complicando las cosas en cuanto a la disponibilidad por territorio, el panorama no ha sido precisamente sencillo.

El producto final: SiriAI

La pobre Siri no ha ganado para disgustos en los últimos años. El salto a los asistentes potenciados por LLMs, capaces de entender lo que les pedimos más allá de simplemente detectar comandos e interpretarlos, la pilló a contrapié. El problema se agravó cuando Apple prometió mejoras y un cambio de arquitectura que terminó siendo fallido. Resultó que el pecado original de los LLMs, las alucinaciones, no permitió lanzar el producto con un porcentaje de fallo suficientemente bajo para los estándares de la marca.

SwiftUI suele actualizar una vista cuando cambia alguno de los datos de los que depende. Cambia un @State, se modifica un @Observable, llega un nuevo valor a través de un Binding, y el cuerpo (variable calculada body) de la vista se vuelve a reevaluar. Ese modelo encaja muy bien con la mayoría de interfaces, pero no siempre basta.

Hay vistas cuyo contenido cambia aunque el estado de la aplicación no haya cambiado realmente. Un reloj, una cuenta atrás, un indicador que representa el progreso de un proceso temporal, una animación paso a paso o una visualización que depende del instante actual no necesitan necesariamente almacenar un nuevo valor cada segundo. Lo que necesitan es que SwiftUI vuelva a evaluar la vista siguiendo una línea de tiempo.

SwiftUI ha simplificado enormemente la creación de interfaces con animaciones. Lo que en UIKit requería bloques de animación, cálculos de estado intermedio y coordinación 100% manual, ahora puede conseguirse con apenas unas líneas de código.

De todos modos, a medida que una aplicación crece, surge una duda habitual: ¿debería utilizar .animation(_:value:) o withAnimation(_:_:)?

Aunque ambas opciones producen resultados visualmente similares, su funcionamiento y sus casos de uso son distintos. Comprender estas diferencias ayuda a construir interfaces más predecibles, fáciles de mantener y con menos efectos secundarios inesperados.