Durante años, throws ha tenido una limitación peculiar dentro de un lenguaje tan orientado al sistema de tipos como Swift: una función podía avisar de que fallaba, pero no podía expresar en su firma qué tipo concreto de error era capaz de propagar. Para el código que llamaba a esa función, el error recibido por catch era siempre any Error, aunque la implementación solo pudiera lanzar un único enum. Swift 6 corrige esta asimetría con los errores tipados, introducidos por SE-0413.

Codable evita buena parte del código repetitivo necesario para convertir JSON, listas de propiedades y otros formatos en tipos de Swift. Sin embargo, cuando la estructura recibida no coincide con el modelo, la experiencia cambia por completo. El error contiene casi siempre la información necesaria para localizar el problema, pero hasta ahora aparecía enterrada entre nombres de tipos, valores opcionales y representaciones internas de cada CodingKey.

Swift 6.3 mejora esta situación mediante SE-0489. La propuesta hace que DecodingError y EncodingError adopten CustomDebugStringConvertible, de modo que su representación de depuración muestre el tipo de fallo, la ruta hasta el valor problemático y el contexto de una forma mucho más directa.

Crear interfaces que se adapten correctamente a diferentes tamaños de ventana se ha convertido en una necesidad cada vez más importante dentro del ecosistema Apple. SwiftUI lleva años ofreciendo herramientas para construir interfaces flexibles, pero durante mucho tiempo muchas soluciones han terminado recurriendo a GeometryReader, tamaños calculados manualmente o valores almacenados como estado.

containerRelativeFrame() ofrece una alternativa mucho más declarativa cuando lo único que necesitamos es que una vista mida su tamaño en relación con el contenedor disponible. No necesitamos observar cambios de geometría, almacenar medidas ni introducir estado adicional: describimos la relación entre la vista y su contenedor y dejamos que SwiftUI la resuelva dentro del propio sistema de layout.

Cuando una aplicación necesita que sus datos estén disponibles en el iPhone, el iPad y el Mac del usuario, normalmente aparece una pieza que complica bastante la arquitectura: el backend. Hay que elegir una base de datos, crear una API, autenticar usuarios, controlar permisos, resolver conflictos, gestionar la sincronización y mantener una infraestructura que siga funcionando cuando la aplicación crezca.

CloudKit es la alternativa de Apple para una parte importante de estos casos. Es un servicio integrado con iCloud que permite almacenar datos estructurados, sincronizarlos entre dispositivos y compartirlos entre usuarios sin tener que construir y operar un servidor tradicional.

Una preview de SwiftUI debería permitirnos cambiar una vista y comprobar el resultado casi de inmediato. Sin embargo, esa ventaja desaparece cuando la previsualización necesita iniciar la aplicación, abrir una base de datos o esperar la respuesta de un servidor antes de mostrar contenido. La preview deja de ser una herramienta de diseño rápida y se convierte en otra ejecución frágil de la aplicación.

El problema no está en #Preview. Xcode compila y ejecuta el código que le entregamos, incluida cualquier tarea asíncrona iniciada por la vista. Si esa ruta alcanza el servicio de producción, la previsualización hereda su latencia, sus errores, sus credenciales y su dependencia de la conexión. La solución consiste en separar la obtención de datos mediante un protocolo e inyectar una implementación en memoria con escenarios estáticos.