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.

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.