🧠 SwiftUI utiliza estructuras para describir nuestras vistas. Son valores que podemos construir y sustituir con frecuencia. Pero, cuando añadimos varias propiedades @State, aparece una duda razonable: ¿cuánto cuesta conservar ese estado y cómo se compara con una NSView de AppKit?

La respuesta exige mirar qué representa cada pieza, cuánto trabajo realiza y durante cuánto tiempo existe. Contar clases no basta para comparar el coste de dos interfaces.

Una descripción de vista y una NSView cumplen funciones diferentes

Una estructura que implementa View describe una parte de la interfaz para unos datos concretos. Crear un nuevo valor de esa estructura no equivale a reconstruir todos los recursos que muestran el resultado en pantalla.

Ejecutar un modelo de lenguaje dentro del dispositivo y llamar a otro alojado en la nube ya no tiene por qué traducirse en dos implementaciones independientes. Con las novedades de Foundation Models presentadas en la WWDC26, una app puede usar el modelo local de Apple para las tareas privadas y acotadas, recurrir a Gemini o ChatGPT cuando necesita más contexto o razonamiento y mantener una única API alrededor de LanguageModelSession.

La firma de código es una de esas partes del desarrollo para plataformas Apple que normalmente pasa desapercibida hasta que deja de funcionar. Xcode muestra un mensaje sobre un certificado, otro sobre un perfil de aprovisionamiento y, unos minutos después, uno más indicando que una capability no está permitida. Como todos esos errores aparecen durante la misma fase del build, es fácil pensar que certificados, App IDs, perfiles y entitlements son nombres diferentes para una misma cosa.

Añadir .padding(.horizontal, 16) parece una forma razonable de separar el contenido de los bordes. Hasta que abrimos la misma pantalla en otro dispositivo y el texto deja de alinearse con el título de navegación.

El problema está en asumir que el margen del sistema es una constante. Apple utiliza valores que dependen del contenedor y de la posición de la vista. En el iPhone Duo, además, ambos lados pueden necesitar márgenes distintos.

Embedded Swift sigue evolucionando y ya no parece una variante limitada del lenguaje. Swift 6.4 amplía de forma importante el subconjunto de características disponibles para sistemas embebidos con soporte generalizado para existenciales any, errores no tipados, metatipos completos, parsing de números en coma flotante y operaciones que lanzan errores dentro del modelo de concurrencia. El objetivo continúa siendo el mismo: permitir escribir Swift expresivo y seguro en dispositivos con recursos muy limitados sin arrastrar los costes habituales del runtime completo.