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.

El iPhone Duo introduce un problema de diseño que no se resuelve simplemente adaptando la interfaz al ancho disponible. Cuando el dispositivo está parcialmente plegado, una vista puede quedar justo encima de la bisagra. Y aunque SwiftUI siga distribuyendo sus elementos correctamente desde el punto de vista geométrico, leer un texto o pulsar un botón situado en esa zona resulta incómodo.

Con iOS 27.1, SwiftUI incorpora una herramienta para abordar este escenario: las regiones reservadas (ReservedRegion). Nos permiten saber qué partes del espacio de una vista están ocupadas o divididas por elementos que no controlamos, como una cámara o el pliegue de una pantalla.

Presentar un formulario sobre otra pantalla suele resolverse con .sheet. Sin embargo, cuando la pantalla tiene espacio para mostrar la presentación y parte del contenido original, su posición también influye en la experiencia. Un editor situado a un lado puede dejar visible información que necesitamos consultar mientras trabajamos.

SwiftUI incorpora desde iOS 27 el modificador .presentationPlacement(_:) para indicar dónde queremos colocar esa presentación. En iPhone Duo, la elección resulta especialmente visible al utilizar la pantalla interior.

Un print("Error al guardar") permite comprobar rápidamente si entramos en una rama del código. Pero cuando aparecen decenas de mensajes, cuesta reconstruir qué ocurrió y desde qué componente. Y si el fallo sucede en el dispositivo de otra persona, necesitamos algo más que la salida de una sesión de depuración.

Apple ofrece un sistema de registro unificado que incorpora niveles de severidad, categorías y controles de privacidad. Su API Logger, disponible desde iOS 14 y macOS 11, permite registrar información que después podemos consultar con herramientas del sistema.

Cuando una app termina inesperadamente, el código encargado de explicar qué ha pasado tiene un problema: puede estar ejecutándose dentro del mismo proceso que acaba de fallar. Si hay corrupción de memoria o recursos bloqueados, recopilar información deja de ser una operación sencilla. CrashReportExtension, disponible desde iOS 27, permite trasladar ese trabajo a una extensión que se ejecuta en otro proceso. Apple documenta este modelo en la presentación del framework.

La separación es la novedad más interesante. La app que ha fallado pasa a ser el objeto de análisis y la extensión se encarga de inspeccionarla. Esto permite organizar el diagnóstico con tipos de Swift y APIs de Foundation sin ejecutar toda esa lógica dentro de un manager en el proceso afectado. Aun así, conviene mantener la extensión sin mucha complejidad: recibir un fallo no debería implicar inicializar todas las librerías y servicios de la aplicación.