Con Swift 6, organizar una aplicación SwiftUI ya no consiste únicamente en separar vistas, modelos y servicios. También hay que decidir qué código puede acceder a cada estado y desde qué contexto de concurrencia. Muchos errores relacionados con Sendable o @MainActor aparecen precisamente porque esas responsabilidades se han mezclado.

Una forma práctica de diseñar la arquitectura es hacerse una pregunta antes de crear cada tipo: ¿qué estado necesita conservar? A partir de la respuesta podemos distinguir el estado de la interfaz, el estado compartido que no pertenece a la interfaz y las operaciones que no necesitan guardar estado.

Las enumeraciones son una de las herramientas más expresivas de Swift. Un switch exhaustivo obliga a contemplar todos sus casos y convierte muchos cambios del modelo en errores de compilación fáciles de localizar. Esa ventaja, sin embargo, se convierte en una limitación cuando la enumeración forma parte de la API pública de un paquete.

Desde Swift 6.2.3, la propuesta SE-0487 permite marcar una enumeración con @nonexhaustive. El atributo comunica que los casos publicados son los conocidos hoy, pero que podrían aparecer más en versiones posteriores.

El iPhone Duo introduce un problema de diseño que no se resuelve simplemente adaptando la interfaz al ancho disponible. Cuando el dispositivo está parcialmente plegado, una vista puede quedar justo encima de la bisagra. Y aunque SwiftUI siga distribuyendo sus elementos correctamente desde el punto de vista geométrico, leer un texto o pulsar un botón situado en esa zona resulta incómodo.

Con iOS 27.1, SwiftUI incorpora una herramienta para abordar este escenario: las regiones reservadas (ReservedRegion). Nos permiten saber qué partes del espacio de una vista están ocupadas o divididas por elementos que no controlamos, como una cámara o el pliegue de una pantalla.

Presentar un formulario sobre otra pantalla suele resolverse con .sheet. Sin embargo, cuando la pantalla tiene espacio para mostrar la presentación y parte del contenido original, su posición también influye en la experiencia. Un editor situado a un lado puede dejar visible información que necesitamos consultar mientras trabajamos.

SwiftUI incorpora desde iOS 27 el modificador .presentationPlacement(_:) para indicar dónde queremos colocar esa presentación. En iPhone Duo, la elección resulta especialmente visible al utilizar la pantalla interior.

Un print("Error al guardar") permite comprobar rápidamente si entramos en una rama del código. Pero cuando aparecen decenas de mensajes, cuesta reconstruir qué ocurrió y desde qué componente. Y si el fallo sucede en el dispositivo de otra persona, necesitamos algo más que la salida de una sesión de depuración.

Apple ofrece un sistema de registro unificado que incorpora niveles de severidad, categorías y controles de privacidad. Su API Logger, disponible desde iOS 14 y macOS 11, permite registrar información que después podemos consultar con herramientas del sistema.