Durante años, una de las partes más difíciles de Swift Concurrency no ha sido aprender async y await, sino entender dónde se ejecuta realmente el código. Una función asíncrona podía abandonar el actor desde el que se llamaba aunque no hubiésemos pedido ningún paralelismo. Swift 6.2 cambia ese comportamiento con una de las piezas más importantes de Approachable Concurrency: NonisolatedNonsendingByDefault.

El cambio parte de una idea sencilla: ser async no debería significar automáticamente “ejecutarse en otro sitio”. Una función asíncrona necesita poder suspenderse, pero eso no implica que deba abandonar el contexto de aislamiento del llamador. Con Swift 6.2, el lenguaje avanza hacia un modelo en el que el código permanece serializado por defecto y somos nosotros quienes expresamos de forma explícita cuándo queremos introducir concurrencia real.

El foco parece un detalle menor hasta que construimos un formulario con varios campos de texto. Entonces aparecen necesidades muy concretas: colocar automáticamente el cursor en un campo, moverlo al siguiente al pulsar Next, volver al dato que contiene un error o cerrar el teclado cuando la edición termina. Desde iOS 15, SwiftUI permite resolver todos estos casos de forma declarativa mediante @FocusState.

La idea encaja perfectamente con el modelo de SwiftUI. En lugar de pedir directamente a un UITextField que se convierta en first responder, declaramos qué elemento debería tener el foco en cada momento y dejamos que el framework sincronice ese estado con la interfaz. Además, la relación funciona en ambas direcciones: si el usuario toca un campo, @FocusState se actualiza; si modificamos el estado desde nuestro código, SwiftUI mueve el foco a la vista correspondiente.

Una pantalla puede necesitar varias consultas para completar su contenido. Si esperamos a reunir todos los resultados antes de actualizarla, la petición más lenta determina cuánto tiempo permanece vacía. Aunque algunas secciones estén listas, el usuario sigue viendo un indicador de carga.

Una de las mejores maneras de acabar con esto, es organizar el trabajo por etapas con AsyncSequence. Este enfoque permite entregar resultados parciales y decidir qué contenido aparece primero. La mejora puede estar en el tiempo hasta el primer resultado útil, aunque completar toda la pantalla siga costando lo mismo o incluso más.

Medir cuánto tarda en ejecutarse una operación parece uno de los problemas más sencillos de programación. Guardamos la hora antes, ejecutamos el código, volvemos a consultar la hora y restamos ambos valores. Durante años, en Swift ha sido habitual resolverlo con Date, CFAbsoluteTimeGetCurrent() o DispatchTime. El problema es que no todos esos relojes representan el mismo concepto de tiempo y elegir el incorrecto puede producir mediciones que no significan exactamente lo que creemos.

Tener un buscador dentro de una app está bien. Pero poder llegar a él diciendo «Busca taladros en Taller» ahorra unos cuantos pasos. Con App Intents podemos conectar esa petición con nuestra pantalla de resultados y conservar la experiencia de búsqueda que ya hemos construido.

La integración requiere algo más que abrir la aplicación: hay que transmitir la consulta, mostrar la pantalla adecuada y hacer que ambos caminos, la voz y el teclado, utilicen el mismo estado.