Durante años, buena parte de la sintaxis declarativa de SwiftUI se ha apoyado en distintos result builders. ViewBuilder construía jerarquías de vistas, ToolbarContentBuilder hacía lo propio con barras de herramientas y CommandsBuilder resolvía los comandos de una aplicación. El resultado era una API muy expresiva para nosotros, pero bastante más complicada para el compilador de lo que podía parecer a simple vista.

Con Xcode 27, Apple da un paso importante para simplificar ese modelo mediante ContentBuilder, un constructor unificado capaz de construir distintos tipos de contenido sin imponer de entrada que cada expresión cumpla un protocolo concreto. El cambio está orientado principalmente a mejorar el rendimiento de la comprobación de tipos y, aunque en la mayoría de proyectos apenas exige modificar código, sí cambia de forma relevante la arquitectura interna con la que SwiftUI interpreta nuestros bloques declarativos.

Una vista modal parece una pieza bastante resuelta de cualquier aplicación: se presenta, permite completar una tarea y se cierra. En iPhone Duo hay otra variable que revisar: el espacio disponible cambia al abrir, girar o plegar el dispositivo. Una presentación que resulta cómoda sobre una pantalla plana puede situar sus acciones justo en la zona curvada cuando el usuario cambia de postura.

Apple explica en Design for iPhone Duo que las hojas del sistema adaptan su tamaño, posición y barras de herramientas. En la pantalla exterior pueden mostrar los controles en una barra vertical; en la interior utilizan barras horizontales. Al plegar parcialmente el dispositivo, pueden desplazarse para evitar quedar apoyadas sobre el pliegue. La presentación tiene su propio contexto: la orientación de sus controles no tiene por qué coincidir con la de la aplicación situada detrás.

Cuando construimos interfaces con SwiftUI solemos pensar en la alineación como una propiedad bastante sencilla: un VStack puede alinear su contenido a .leading, .center o .trailing, mientras que un HStack permite decidir cómo se distribuyen verticalmente sus elementos.

Sin embargo, por debajo de esa API aparentemente simple existe un mecanismo bastante más potente: las guías de alineación (alignment guides).

Una guía de alineación representa una coordenada dentro de una vista. El contenedor consulta esa coordenada en cada uno de sus hijos y los posiciona de forma que todas esas referencias coincidan.

En ocasiones, Xcode asegura que una API no existe aunque aparezca claramente en la documentación de Apple. El nombre está bien escrito, la versión mínima del sistema es correcta y el tipo parece pertenecer al módulo que ya hemos importado. Sin embargo, el compilador responde con un cannot find ... in scope o indica que una vista no contiene el modificador que queremos utilizar.

Detrás de algunos de estos errores están los cross-import overlays: módulos auxiliares que Swift carga automáticamente cuando un mismo archivo importa una dupla concreta de módulos. No solemos verlos ni escribir su nombre, pero explican por qué determinadas APIs solo aparecen al combinar dos import.

Las interfaces de las aplicaciones para sistemas Apple ya no pueden diseñarse pensando únicamente en un conjunto reducido de tamaños de pantalla. En iPad las ventanas se pueden redimensionar libremente y, con iOS 27, las aplicaciones de iPhone compiladas con el SDK más reciente también pueden cambiar de tamaño cuando se ejecutan en un iPad o mediante iPhone Mirroring en el Mac.

Esto hace que decisiones tradicionales como comprobar el modelo del dispositivo, el userInterfaceIdiom o incluso la orientación de la interfaz sean cada vez menos apropiadas para decidir cómo organizar una vista. Lo importante ya no es tanto en qué dispositivo se ejecuta la aplicación, sino cuánto espacio tiene realmente disponible en ese momento.