En ocasiones, Xcode asegura que una API no existe aunque aparezca claramente en la documentación de Apple. El nombre está bien escrito, la versión mínima del sistema es correcta y el tipo parece pertenecer al módulo que ya hemos importado. Sin embargo, el compilador responde con un cannot find ... in scope o indica que una vista no contiene el modificador que queremos utilizar.

Detrás de algunos de estos errores están los cross-import overlays: módulos auxiliares que Swift carga automáticamente cuando un mismo archivo importa una dupla concreta de módulos. No solemos verlos ni escribir su nombre, pero explican por qué determinadas APIs solo aparecen al combinar dos import.

Las interfaces de las aplicaciones para sistemas Apple ya no pueden diseñarse pensando únicamente en un conjunto reducido de tamaños de pantalla. En iPad las ventanas se pueden redimensionar libremente y, con iOS 27, las aplicaciones de iPhone compiladas con el SDK más reciente también pueden cambiar de tamaño cuando se ejecutan en un iPad o mediante iPhone Mirroring en el Mac.

Esto hace que decisiones tradicionales como comprobar el modelo del dispositivo, el userInterfaceIdiom o incluso la orientación de la interfaz sean cada vez menos apropiadas para decidir cómo organizar una vista. Lo importante ya no es tanto en qué dispositivo se ejecuta la aplicación, sino cuánto espacio tiene realmente disponible en ese momento.

Escribir [weak self] suele transmitir una intención muy clara: el bloque no debe prolongar la vida del objeto. Sin embargo, cuando esa captura aparece dentro de otro bloque, el resultado puede ser justo el contrario. El bloque interior utiliza una captura de referencia débil, pero el exterior puede haber capturado self fuertemente para poder crearla.

Swift 6.4 incorpora un diagnóstico específico para este caso. Al compilar con Xcode 27, el aviso indica que la propiedad de la captura débil no coincide con la referencia fuerte capturada implícitamente en el ámbito exterior:

Las barras de herramientas de SwiftUI siempre han tenido cierto comportamiento adaptativo. Podemos declarar varios ToolbarItem y dejar que el sistema decida cómo colocarlos según la plataforma, el tamaño de la ventana o el espacio disponible. El problema aparece cuando esa decisión automática no coincide con la importancia real de cada acción.

En una ventana amplia todo puede parecer correcto, pero al reducirla —o al ejecutar la misma interfaz en un iPhone— algunos botones terminan en el menú de desbordamiento. Hasta ahora teníamos pocas herramientas para indicarle a SwiftUI qué acciones debían conservarse a la vista y cuáles podían desaparecer primero.

Apple ha presentado iPhone Duo, su primer iPhone plegable, y junto al nuevo hardware llega una cuestión especialmente importante para quienes desarrollamos aplicaciones: qué ocurre con todo el software existente cuando se ejecuta en una pantalla interior de 7,6 pulgadas con una geometría completamente nueva.

La respuesta de Apple es bastante pragmática. Las aplicaciones actuales siguen funcionando sin necesidad de recompilarlas, pero el sistema aumenta progresivamente el área disponible dependiendo del SDK con el que se haya construido cada versión. En la práctica, iPhone Duo introduce tres niveles de compatibilidad: aplicaciones anteriores a iOS 27, aplicaciones compiladas con el SDK de iOS 27.0 y aplicaciones preparadas específicamente con iOS 27.1.