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.

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.