Toggle es uno de los controles más sencillos de SwiftUI, pero su apariencia por defecto no siempre encaja con el diseño de una aplicación. Aunque podemos utilizar estilos integrados como .switch o .button, SwiftUI también permite sustituir por completo su representación visual mediante el protocolo ToggleStyle.

La ventaja de utilizar un estilo en lugar de construir un control independiente es que seguimos trabajando con Toggle, con su Binding, su etiqueta y su integración dentro de la jerarquía de SwiftUI. El componente conserva su intención semántica mientras la presentación queda desacoplada del lugar donde se utiliza.

Una guía de montaje implementada con List o un VStack puede mostrar un aviso al llegar al último paso. Para hacerlo necesitamos observar la posición del contenido, pero guardar cada desplazamiento en un @State introduce actualizaciones que esa pantalla no necesita. La información útil es una condición: estamos al final o todavía queda recorrido.

Desde iOS 18 y macOS 15, SwiftUI ofrece onScrollGeometryChange para reaccionar a la geometría de una vista desplazable. Forma parte de las mejoras de desplazamiento presentadas en la WWDC24. Permite resolver este caso sin montar una cadena de GeometryReader y preferencias para transmitir las medidas.

Swift 6.4 ya está disponible. La nueva versión combina cambios que simplifican funciones cotidianas con herramientas para controlar mejor la memoria y seguir llevando Swift a otras plataformas. Entre tantas novedades, merece la pena detenerse en las que resuelven problemas concretos: terminar una operación asíncrona correctamente, gestionar avisos durante una migración o almacenar recursos que no se pueden copiar. El anuncio oficial recoge el lanzamiento.

Una de las incorporaciones más prácticas es poder utilizar await dentro de defer. Hasta ahora, una limpieza de recursos asíncrona obligaba a repetir llamadas en varias rutas de salida o lanzar una tarea independiente. Con Swift 6.4, un contexto asíncrono puede esperar ese trabajo al abandonar el ámbito, tanto si termina normalmente como si propaga un error. Los bloques siguen ejecutándose en orden inverso al de su declaración. Así lo define SE-0493.

MVVM sigue siendo uno de los patrones más utilizados para estructurar aplicaciones SwiftUI, pero también uno de los que se aplican con mayor automatismo. Crear un ViewModel para cada View puede parecer coherente y, aun así, terminar repartiendo el código que maneja una pantalla sencilla entre demasiados archivos sin obtener una separación real y aumentando la complejidad.

Una idea bastante útil es empezar sin modelo de vista y extraerlo cuando aparezca lógica de presentación que merezca vivir y probarse por separado. SwiftUI ya proporciona estado, enlaces y valores del entorno; MVVM debe resolver un problema concreto, no convertirse en un requisito administrativo.

En SwiftUI, que cambie un dato no implica necesariamente que se vuelva a evaluar el body de todas las vistas que lo reciben. Tampoco una nueva evaluación equivale por sí sola a dibujar de nuevo toda la interfaz. SwiftUI mantiene un grafo de dependencias, calcula de nuevo las ramas afectadas y decide después qué cambios deben reflejarse en pantalla.

La parte menos evidente es que no todas las entradas crean la misma clase de dependencia. Una propiedad almacenada, un @Binding, un valor del entorno y una propiedad de un modelo @Observable pueden contener información equivalente, pero provocan actualizaciones distintas.