Últimos articulos

La respuesta háptica se ha convertido en una parte fundamental de la experiencia de usuario en los dispositivos de Apple. Una ligera vibración puede confirmar una acción, advertir de un error o reforzar una interacción sin necesidad de mostrar información adicional en pantalla.

Hasta hace relativamente poco, integrar este tipo de comportamiento en una aplicación SwiftUI implicaba recurrir a UIKit y utilizar clases como UIImpactFeedbackGenerator o UINotificationFeedbackGenerator. Afortunadamente, SwiftUI incorpora una API mucho más sencilla y declarativa: sensoryFeedback.

SwiftUI siempre ha apostado por que las barras de herramientas se adapten automáticamente a cada plataforma. El mismo código puede distribuir los elementos de forma distinta en iPhone, iPad o Mac para ofrecer la mejor experiencia posible. Sin embargo, esa flexibilidad también supone perder cierto control sobre qué acciones permanecen visibles y cuáles terminan ocultas.

Con SwiftUI en Xcode 27 llegan varias APIs que permiten ajustar ese comportamiento sin renunciar a la adaptación automática del sistema.

🛡️ Swift 6.4 introduce withTaskCancellationShield(operation:), una API pequeña pero muy interesante dentro del modelo de concurrencia de Swift. Su objetivo no es cambiar cómo funciona la cancelación de tareas, sino cubrir un caso muy concreto: ejecutar un bloque de código para restaurar el estado aunque la tarea ya haya sido cancelada.

🧩 En Swift, la cancelación de tareas es cooperativa. Cancelar una Task no detiene el código de forma brusca. Lo que ocurre es que la tarea queda marcada como cancelada, y el propio código decide cuándo reaccionar consultando Task.isCancelled o llamando a Task.checkCancellation().

🧭 Swift 6.4 no es una versión pensada únicamente para generar grandes titulares. Muchas de sus novedades van en otra dirección: reducir pequeñas fricciones, hacer más explícitas algunas intenciones del código y facilitar migraciones reales en proyectos que ya tienen varios años de vida. Es justo la idea que transmite la sesión What’s new in Swift de la WWDC26: cambios pequeños en apariencia, pero bastante útiles cuando los llevas a una app de verdad.

🤖 Foundation Models está dejando de ser una API pensada únicamente para invocar el modelo local de Apple. Con las novedades presentadas en la WWDC26, el framework empieza a comportarse como una capa de abstracción para trabajar con distintos modelos de lenguaje desde Swift: el modelo en dispositivo, Private Cloud Compute, implementaciones locales basadas en Core AI o MLX, y proveedores externos como Anthropic o Google.

La idea es muy potente porque cambia totalmente el enfoque de la integración. En lugar de diseñar una capa distinta para cada proveedor, la aplicación puede trabajar contra LanguageModelSession y dejar que el modelo concreto sea una dependencia intercambiable. Si el caso de uso requiere privacidad, baja latencia y funcionamiento offline, puede usarse el modelo en dispositivo. Si se necesita más contexto, razonamiento más avanzado o herramientas de servidor, se puede escalar a un modelo remoto como Claude manteniendo la misma forma general de construir prompts, pedir respuestas estructuradas o procesar las respuestas.