Extraer código repetido suele parecer una mejora evidente. Dos pantallas muestran algo parecido, creamos un componente y ambas lo utilizan. Después llega una necesidad exclusiva de una pantalla. Añadimos un booleano. Más adelante aparece otra excepción y añadimos otro.

El resultado puede seguir llamándose «compartido», aunque cada consumidor utilice una parte diferente. Podemos describir este problema como una convivencia entre responsabilidades que han dejado de encajar. La reutilización pierde valor cuando obliga a coordinar decisiones que deberían evolucionar por separado.

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.