Últimos articulos

🧭 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.

🔐 Guardar datos sensibles en una aplicación iOS parece una decisión sencilla hasta que aparece la primera duda importante: ¿dónde debería vivir un token de sesión, una clave privada, una credencial temporal o un identificador que no queremos exponer? La respuesta corta suele ser Keychain, pero la respuesta buena es necesario matizarla más. El Keychain no es simplemente “un UserDefaults seguro”; es un servicio del sistema con reglas de acceso, cifrado, grupos de acceso compartido y clases protegidas que conviene entender antes de meter ahí cualquier valor.

SwiftUI lleva años apoyándose en una idea muy potente: describir interfaces mediante pequeños bloques declarativos. Escribimos VStack, List, ToolbarItem, CommandMenu o Tab, y dentro de sus closures vamos declarando el contenido que queremos mostrar. Esa sintaxis parece natural, pero detrás hay una pieza del lenguaje Swift que hace mucho trabajo por nosotros: los result builders.

Durante mucho tiempo, el nombre más visible dentro de SwiftUI ha sido @ViewBuilder. Lo hemos usado para crear vistas compuestas, propiedades calculadas, inicializadores de componentes reutilizables y bloques de código que devuelven some View. Sin embargo, SwiftUI ya no se limita a construir simples vistas. También construye barras de herramientas, comandos de menú, pestañas, escenas, animaciones y otros tipos de contenido declarativo.

SwiftUI lleva años empujándonos hacia una idea muy concreta: la interfaz debe ser una consecuencia directa del estado. Si hay datos, se muestra una vista. Si esos datos desaparecen, la vista también desaparece. Es una idea sencilla que cuando se aplica bien elimina mucha lógica accidental y hace que la navegación de la aplicación sea predecible.

Hasta ahora, esa filosofía estaba muy clara en APIs como sheet(item:), popover(item:) o navigationDestination(item:). En todas ellas, la presentación depende de un valor opcional. Cuando el valor pasa a ser distinto de nil, SwiftUI presenta el contenido. Cuando la presentación se cierra, el valor vuelve a nil.