Últimos articulos

SwiftUI ha simplificado enormemente la creación de interfaces con animaciones. Lo que en UIKit requería bloques de animación, cálculos de estado intermedio y coordinación 100% manual, ahora puede conseguirse con apenas unas líneas de código.

De todos modos, a medida que una aplicación crece, surge una duda habitual: ¿debería utilizar .animation(_:value:) o withAnimation(_:_:)?

Aunque ambas opciones producen resultados visualmente similares, su funcionamiento y sus casos de uso son distintos. Comprender estas diferencias ayuda a construir interfaces más predecibles, fáciles de mantener y con menos efectos secundarios inesperados.

Hasta ahora, si queríamos permitir que los usuarios reorganizasen elementos en una interfaz SwiftUI, la solución más habitual era recurrir a List y su modificador onMove. El problema era que muchas interfaces modernas ya no utilizan las listas tradicionales: dashboards, cuadrículas, paneles personalizables, carruseles horizontales o layouts completamente personalizados quedaban fuera de esta experiencia.

Con iOS 27, SwiftUI introduce una nueva API que generaliza este comportamiento mediante los modificadores reorderable() y reorderContainer(...), permitiendo implementar una reordenación nativa en prácticamente cualquier contenedor de vistas. Esta novedad supone un cambio conceptual importante: la reordenación deja de ser una característica exclusiva de List para convertirse en una capacidad que cualquier contenedor puede adoptar.

Con iOS 27, SwiftUI añade una nueva capa sobre el sistema de drag & drop (arrastrar y soltar): los nuevos Drag Containers. A primera vista puede parecer una variante más de .draggable, pero el cambio de modelo es bastante interesante.

Hasta ahora, lo habitual era que cada vista draggable conociese el objeto completo que iba a arrastrarse. Con la nueva API, una vista hija puede limitarse a exponer un identificador, mientras que el contenedor se encarga de convertir esos identificadores en valores reales que conforman Transferable cuando comienza el arrastre.

Durante la WWDC 2026 Apple presentó numerosos cambios en SwiftUI, algunos muy visibles y otros más discretos. Entre estos últimos se encuentra una modificación especialmente interesante para quienes desarrollamos interfaces declarativas a diario: @State deja de estar implementado como un property wrapper tradicional y pasa a convertirse en una macro del lenguaje Swift.

A primera vista parece un detalle interno sin demasiada relevancia. Seguimos escribiendo exactamente el mismo código que escribíamos ayer. Sin embargo, este cambio resuelve algunas ineficiencias históricas de SwiftUI y mejora especialmente la integración con el nuevo sistema de Observation.

Con las últimas versiones de SwiftUI, Apple sigue ampliando las posibilidades de personalización de las transiciones de navegación. Una de las incorporaciones más interesantes es navigationTransition(.crossfade), una transición que sustituye el movimiento tradicional entre pantallas por un fundido gradual entre la vista de origen y la de destino.

A simple vista puede parecer un detalle menor, pero en determinadas interfaces permite crear experiencias mucho más limpias y menos intrusivas, especialmente cuando la jerarquía de navegación no necesita reforzarse de forma explíticita mediante desplazamientos laterales.