Últimos articulos

Binding es una de las piezas fundamentales del flujo de datos en SwiftUI. Permite que una vista lea y modifique un valor cuya propiedad pertenece a otro ámbito, sin convertirse por ello en su fuente de verdad. En los casos sencillos, el propio framework crea esa conexión mediante la sintaxis $: un TextField recibe $model.name, un Toggle recibe $settings.notificationsEnabled y la vista no necesita saber dónde se almacena realmente el dato.

Una de las ventajas más importantes del sistema Observation es su rendimiento. Cuando una vista lee una propiedad de un modelo marcado con @Observable, SwiftUI registra esa dependencia concreta. Si después cambia otra propiedad del mismo objeto que la vista no utiliza, su body no necesita volver a evaluarse.

Sin embargo, observar por propiedades no resuelve de por sí todos los cálculos innecesarios. También importa qué entiende Swift por «cambio». En las versiones actuales de la macro @Observable, el tipo de la propiedad determina si una asignación con el mismo valor genera una notificación. Una conformidad aparentemente sencilla como Equatable puede evitar reevaluaciones completas de una vista.

SwiftUI siempre ha defendido que la interfaz debe ser una consecuencia del estado. Si existe un dato, se muestra una vista; si el dato desaparece, también lo hace su representación. Sin embargo, hasta ahora las alertas y los diálogos de confirmación no terminaban de encajar en ese modelo. En muchos casos había que combinar un Binding<Bool> con otro valor que almacenase el elemento sobre el que debía actuar la presentación.

SwiftUI utiliza el los entornos para propagar configuraciones y dependencias a través de la jerarquía de vistas. Valores del sistema como locale, colorScheme o dynamicTypeSize llegan por esta vía, pero también podemos definir los nuestros propios mediante el macro @Entry.

La sintaxis es tan sencilla que resulta fácil pasar por alto un detalle importante: el valor por defecto no debe cambiar cada vez que SwiftUI lo consulta. Si la expresión crea una instancia nueva en cada acceso, una dependencia que parecía constante puede provocar reevaluaciones innecesarias de las vistas.

Los inicializadores memberwise son una de esas características de Swift que utilizamos constantemente sin prestarles demasiada atención. Declaramos una estructura, añadimos varias propiedades almacenadas y el compilador genera por nosotros un inicializador con los parámetros necesarios. Es una pequeña comodidad, pero fundamental para que los tipos por valor queden más compactos y sean más expresivos.

Sin embargo, esta síntesis automática siempre ha tenido reglas menos intuitivas de lo que parece. Los valores por defecto, las propiedades let, el control de acceso y la ubicación de otros inicializadores pueden cambiar la firma generada o incluso hacerla inaccesible. Swift 6.4 mejora uno de los casos más molestos mediante la SE-0502: una propiedad privada que ya puede inicializarse por sí misma deja de inutilizar el inicializador que necesitan el resto de propiedades.