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.

Que una aplicación pueda ejecutarse en un dispositivo nuevo no significa que esté preparada para aprovecharlo. El iPhone Duo es un buen ejemplo: las versiones que ya están publicadas continúan funcionando sin que sus desarrolladores tengan que recompilarlas, pero iOS modifica el espacio que les concede según el SDK con el que se construyeron.

Una aplicación antigua aparece dentro de una superficie protegida, otra compilada con el SDK de iOS 27 utiliza una parte mayor de la pantalla interior y una construida con iOS 27.1 puede adoptar la experiencia completa. La compatibilidad está garantizada; la adaptación, no.

Los sheet llevan años siendo una de las herramientas más habituales de SwiftUI para presentar contenido temporal. En el iPhone cuando está en vertical, el patrón funciona especialmente bien: la vista aparece desde la parte inferior, puede adoptar diferentes alturas mediante detents y mantiene clara la jerarquía entre el contenido principal y el modal.

El problema aparece cuando dejamos de pensar en una pantalla de iPhone con dimensiones prácticamente fijas. Con iOS 27, las aplicaciones de iPhone deben estar preparadas para ejecutarse en entornos redimensionables, incluyendo iPhone Mirroring y diferentes tamaños disponibles al ejecutarse en un iPad. En ese contexto, una presentación que siempre crece desde la parte inferior deja de ser necesariamente la mejor solución. En una ventana ancha y relativamente baja, un panel lateral puede aprovechar mucho mejor el espacio disponible.

Durante años, hablar de Swift para la web ha significado casi siempre hablar del lado servidor. Vapor y Hummingbird permiten construir servicios HTTP, APIs y aplicaciones completas sin abandonar el lenguaje, pero la interfaz que recibe el navegador continúa escribiéndose normalmente con HTML, CSS y JavaScript. ElementaryUI propone dar un paso más: compilar Swift a WebAssembly y ejecutar en el navegador una interfaz declarativa y reactiva inspirada en SwiftUI.

El proyecto no ha aparecido de la nada. Su base es Elementary, una librería creada por Simon Leeb para generar HTML desde Swift en el servidor. ElementaryUI reutiliza esa misma sintaxis de elementos HTML, pero sustituye la salida de texto por nodos reales del DOM y añade estado, eventos, ciclo de vida y animaciones. Son dos piezas relacionadas, aunque todavía conviene entenderlas por separado.

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.