Rendimiento e interoperabilidad de SwiftUI en iOS 27

Un LazyVStack no sabe qué tan alto es. Estima su propia altura a partir del tamaño promedio de las vistas que ya ha colocado y la cantidad que espera que falten, y luego corrige esa estimación en vivo a medida que haces scroll.¹ Tres sesiones de la WWDC26 del equipo de UI Frameworks toman ese único hecho (y sus análogos en gráficos e interoperabilidad) y lo convierten en un modelo funcional de cómo se comporta SwiftUI bajo carga en iOS 27: cómo el scroll se mantiene fluido, cómo se componen los efectos de GPU y cómo SwiftUI encaja en una app de AppKit o UIKit que ya enviaste.

Las tres sesiones se leen como un solo argumento expuesto de tres maneras. Los lazy stacks rinden bien cuando dejas de pelear contra su estimación; los efectos de shader se componen cuando tratas cada modificador como una etapa de una canalización; y la interoperabilidad funciona cuando dejas que @Observable y los protocolos representables sostengan la costura. Ninguna de las tres es el anuncio de una función. Cada una es un mecanismo explicado lo suficientemente bien como para que puedas predecir el framework en lugar de adivinarlo.

TL;DR / Puntos clave

• Un LazyVStack solo evalúa las vistas que llenan el rect visible; las alturas fuera de pantalla y el offset del contenido son estimados, así que las lecturas absolutas de offset de contenido son inestables y deberías preferir APIs de visibilidad relativa como .onScrollTargetVisibilityChange.¹²
• El prefetching reparte el trabajo de mostrar una vista a lo largo de varios frames antes de que aparezca; configura las vistas en su inicializador (no en onAppear) para que el trabajo precargado no se descarte.¹
• Evita una cantidad dinámica de subvistas en una hoja de ForEach: filtrar con un condicional en el body mantiene vivas las vistas por índice, así que filtra a nivel de datos (un Predicate sobre un Query) en su lugar.¹
• SwiftUI expone tres puntos de entrada de shaders (colorEffect, distortionEffect, layerEffect), que aumentan en potencia; solo layerEffect puede muestrear píxeles vecinos, que es lo que necesitan el blur y el domain-warp.³⁴⁵⁶
• Los shaders no tienen estado, así que la animación viene de pasarle como parámetro una marca de tiempo de un TimelineView; nada se traslada entre frames.³⁷
• AppKit y UIKit obtienen redibujado automático desde @Observable (se acabó el needsDisplay manual), y SwiftUI se integra en una app existente a través de NSHostingView, NSGestureRecognizerRepresentable, NSHostingMenu y NSHostingSceneRepresentation.⁸⁹¹⁰

Los lazy stacks funcionan con estimaciones

Lo primero que hay que interiorizar sobre un lazy stack es que cambia corrección por eficiencia a propósito. A diferencia de un VStack, un LazyVStack no evalúa ni renderiza vistas que no están visibles; coloca sus vistas de arriba hacia abajo y se detiene una vez que el rect visible está lleno, agregando vistas a medida que entran con el scroll y quitándolas a medida que salen.¹ La recompensa es obvia. El costo es sutil: como el stack nunca carga todas las vistas, las alturas de las vistas fuera de pantalla se estiman a partir del promedio de lo que vino antes, el ancho ideal colapsa al ancho de la primera subvista, y el espacio por encima de la región visible es en sí mismo aproximado.¹

Esa estimación no es un bug que esquivas una vez; es el sustrato sobre el que se asienta cualquier otra decisión del lazy stack. La sesión 321 hace concreta la consecuencia con un cambio de orientación. Rota un iPhone y la vista visible más alta se mantiene anclada, pero el stack todavía no ha medido el layout nuevo exacto de las vistas que están por encima de ella. Haz scroll de vuelta hacia arriba y el stack debe reconciliar: corrige el espacio estimado por encima de la región visible y actualiza el offset de contenido de la scroll view por la misma cantidad, de modo que el offset de contenido en la parte superior aterrice en cero.¹ El lazy stack y la scroll view que lo contiene coordinan posición y offset con precisión para que, a medida que las estimaciones se actualizan, la posición relativa de las subvistas visibles nunca dé un salto.¹

El corolario accionable es una regla sobre en qué APIs de scroll confiar. Como el offset absoluto de contenido es estimado, leerlo (con .onScrollGeometryChange, por ejemplo, para ocultar un botón después de 100 puntos) te da un umbral que va a la deriva a medida que las estimaciones se asientan.² La señal estable es la visibilidad relativa. El modificador .onScrollTargetVisibilityChange se dispara cuando cambia el conjunto de subvistas visibles en la scroll view, así que un botón de “desplazarse para mostrar” puede ligar su visibilidad a qué filas están en pantalla, con un umbral (la sesión usa 80%), en lugar de un conteo de píxeles inestable.²¹ La misma lógica condena a .scrollTransition: una transformación que empuja una vista fuera de su frame original puede hacer que el stack crea que una vista visible está fuera de pantalla y la descarte antes de tiempo, así que cualquier transición de scroll debe evitar que vistas que normalmente no serían visibles sean empujadas hacia el rect visible.¹¹¹

Por qué tus structs de vista no son las subvistas

Las subvistas que carga un lazy stack no se mapean uno a uno con los structs de vista que escribiste. Un ForEach de StepView se resuelve en un StepView por paso, pero si el body de cada StepView devuelve dos vistas de nivel superior (un diagrama e instrucciones) sin un layout que las contenga, el stack carga cada una de ellas por separado.¹ El número que le importa al stack es el conteo de subvistas resueltas, no el conteo de structs.

La trampa es un conteo de subvistas dinámico. Si un StepView devuelve una subvista o cero según un valor del entorno, el stack ya no puede confiar en los índices, porque el conteo de vistas anteriores podría cambiar. Así que mantiene vivas las instancias anteriores de StepView por si acaso, lo que significa que un cambio de entorno no relacionado puede disparar evaluaciones del body para vistas que salieron de pantalla con el scroll, y el stack no liberará su estado.¹ La solución es mover el filtro fuera de la vista y hacia los datos: si usas SwiftData, pon la condición en un Predicate sobre el Query para que el conteo de subvistas se conozca sin construir ninguna vista.¹ Desempaquetar un opcional en un body tiene el mismo efecto de mantener-más-tiempo-vivo; el movimiento más limpio es mostrar una ContentUnavailableView más arriba en lugar de dejar que el lazy stack retenga filas parcialmente resueltas.¹

El prefetching es el mecanismo que hace que las estimaciones se sientan rápidas. Mientras haces scroll, una scroll view solo tiene hasta el deadline del frame para actualizar el offset, renderizar vistas y ejecutar tu trabajo de cambio de offset; si mostrar una vista nueva revienta ese presupuesto, el frame se cae y ves un tirón.¹ Para prevenirlo, el lazy stack verifica si hay tiempo de sobra y, si lo hay, hace parte del trabajo de una vista que está por aparecer de forma anticipada (evaluando su body y su layout, incluso repartiendo un LazyHStack anidado entre frames), de modo que para cuando la vista aparece, la mayor parte del trabajo ya está hecha.¹ Por eso la sesión es enfática sobre onAppear: si configuras una vista en onAppear, descartas el trabajo precargado y fuerzas que se rehaga cuando aparece, a veces atrayendo más vistas de las necesarias y degradando el scroll. Configura la vista en su inicializador para que llegue en un estado razonable, y reserva onAppear para trabajo genuinamente ligado a la aparición, como obtener la siguiente página en un scroll infinito.¹ En un scroll invertido, un body puede incluso ejecutarse durante el prefetching mientras que onAppear nunca se dispara en absoluto.¹

Los gráficos avanzados son solo una canalización

La sesión 322 reencuadra los “gráficos avanzados” como composición. Cada modificador de SwiftUI es una tubería que toma datos de entrada, los transforma y los pasa adelante; el resultado avanzado vive en cómo conectas las tuberías, no en ninguna API compleja individual.³ La sesión construye una vista de letras en vivo al estilo de Apple Music encadenando etapas ordinarias: aplica blur a la portada para que retroceda, ejecuta un shader sobre ella, impulsa ese shader con el tiempo y sincroniza el scroll de una transcripción con la misma fuente de tiempo.³

La etapa del shader es donde está la verdadera elección. SwiftUI llama a las funciones de shader de Metal a través de tres puntos de entrada de efectos que escalan en capacidad. colorEffect transforma el color de cada píxel a partir de su posición y su color original, lo cual basta para algo como una conversión a escala de grises.⁴ distortionEffect en cambio mapea una posición a otra (le dices a SwiftUI que muestree el color de esta posición desde aquella posición), lo que maneja deformaciones geométricas sin color involucrado.⁵ layerEffect es el más flexible: le entrega al shader la capa entera de la vista, de modo que el píxel de salida puede muestrear a sus vecinos o la región completa, que es exactamente lo que requieren el blur y las deformaciones más ricas.⁶³

El fondo con domain-warp de la sesión usa layerEffect. Un offset float2 uniforme desplaza cada píxel por la misma cantidad, lo que solo desliza la imagen; el movimiento orgánico necesita variación por píxel, así que el shader muestrea una NoiseTexture precalculada (pasada como una imagen, que llega del lado de Metal como un texture2d) cuyos canales rojo y verde suministran un offset distinto en X y Y en cada coordenada UV.³ Muestrear el ruido una vez retuerce la imagen; muestrearlo dos veces, la segunda vez en una posición que el primer muestreo desplazó, produce blobs que fluyen. Esa técnica de segundo orden es el domain warping, y la sesión apunta a su app de ejemplo descargable con una previsualización en vivo de los parámetros.³

Dos hechos del framework hacen que la animación funcione. Los shaders no tienen estado: no guardan memoria del frame anterior, y la salida depende solo de los parámetros que les pasas.³ Así que el movimiento no puede venir desde dentro del shader; tiene que ser inyectado, y un TimelineView es la tubería que lo suministra, disparándose cada frame con una marca de tiempo en un schedule de animación.⁷³ Pasa esa marca de tiempo al shader, súmala a la posición de muestreo del ruido, y el patrón fluye. El lado de la transcripción reutiliza la misma fuente de tiempo desde la otra dirección: la marca de tiempo de reproducción elige la línea actual (en negrita y nítida, el resto atenuado), y un onChange mantiene esa línea centrada a medida que avanza el tiempo.¹²³ La marca de tiempo flotante sobre la línea activa se posiciona no con offset (que necesitaría los tamaños de ambas vistas) sino con un override de alignment-guide que redefine el punto de un alineamiento de forma semántica, de modo que el borde superior de la subvista se adjunta al borde inferior de su contenedor sin un offset manual.¹³³

SwiftUI se integra en una app de AppKit o UIKit

La sesión de interoperabilidad abre con un punto que reencuadra toda la cuestión de la adopción: la mayoría de las apps ya usan SwiftUI implícitamente. En el nuevo diseño, controles de AppKit como NSSlider, NSSwitch y NSSegmentedControl se renderizan con SwiftUI por debajo, y Liquid Glass también comparte gran parte de su implementación entre frameworks a través de SwiftUI.⁸ Así que “adoptar SwiftUI” es menos una reescritura que una decisión sobre dónde hacer la costura explícita.

El primer paso no necesita SwiftUI en absoluto. AppKit y UIKit ahora observan los tipos @Observable automáticamente: marca una clase de modelo como @Observable, lee sus propiedades dentro de un método de dibujo como drawKnob, y AppKit rastrea cada acceso y redibuja cuando cualquier propiedad accedida cambia, retirando el needsDisplay = true manual que solías escribir cada vez que el valor de un slider afectaba la apariencia de otro.⁸¹⁴ La observación se extiende más allá de draw(_:) hacia updateConstraints(), layout(), updateLayer() y los equivalentes de NSViewController, y UIKit llega todavía más lejos, hacia UIButton, UICollectionViewCell y más.⁸ Está activada por defecto en los lanzamientos de 2026 y es retro-desplegable a macOS 15 (NSObservationTrackingEnabled) e iOS 18 (UIObservationTrackingEnabled) vía Info.plist.⁸

Una vez que el modelo es @Observable, la costura real de SwiftUI es pequeña. La sesión reconstruye un selector de color basado en sliders como un control circular de SwiftUI dibujado con Canvas (una API de modo inmediato análoga a drawRect, con withCGContext para reutilizar código existente de Core Graphics), reutilizando el mismísimo @Observable ColorModel.¹⁵⁸ Para incrustarlo donde AppKit espera una vista, envuélvelo en NSHostingView, una subclase de NSView; como el modelo ya impulsa las actualizaciones, esa envoltura es todo lo que se requiere.¹⁶⁸ El código de gestos existente se traslada sin reescribirlo: un ForceClickGestureRecognizer alcanza una vista de SwiftUI a través de NSGestureRecognizerRepresentable (implementa makeNSGestureRecognizer y handleNSGestureRecognizerAction), luego se adjunta con el modificador ordinario .gesture y coexiste con el propio gesto de arrastre de SwiftUI.¹⁷⁸ La misma familia de representables incluye NSViewRepresentable para incrustar NSViews en la otra dirección.⁸

La costura escala hasta menús y escenas. Una View de SwiftUI que contiene un Button y un Picker se convierte en un menú real a través de NSHostingMenu (una subclase de NSMenu), establecida como el submenú de un NSMenuItem agregado al menú principal, con keyboardShortcut dando a la acción una ruta sin gestos para dispositivos de entrada que no pueden hacer force-click.¹⁸⁸ Escenas enteras de SwiftUI también se adjuntan: un MenuBarExtra alcanza una app existente a través de NSHostingSceneRepresentation, agregado vía addSceneRepresentation en applicationWillFinishLaunching, con el Toggle de una escena Settings controlando si el extra se inserta y la acción de entorno openSettings() abriendo los ajustes desde un @IBAction.¹⁹⁸ El punto de cierre de la sesión es el que sostiene todo el peso: cada API que cubre se incluye en los lanzamientos de 2026 o anteriores, y no hay ninguna expectativa de que una app deba ser enteramente SwiftUI para beneficiarse.⁸ El empuje de modernización tiene un filo más duro en otra parte del ciclo, sin embargo: iOS 27 hace del ciclo de vida basado en escenas de UIKit un requisito de lanzamiento, así que una app que reconstruyas con el SDK más reciente no logra lanzarse si nunca adoptó las escenas.

Lo que el equipo de SwiftUI agregó en los labs

Dos aclaraciones de los group labs del equipo de UI Frameworks de la WWDC26 afinan el modelo de invalidación que describen las sesiones. Ambas están parafraseadas a partir de una grabación transcrita localmente; Apple no publica subtítulos oficiales para los labs, la misma brecha de subtítulos que recorrió el propio Group Lab del equipo de Swift donde los ingenieros del lenguaje respondieron las preguntas sobre concurrencia y hoja de ruta.

Mover código fuera de body hacia una propiedad computada no compra ningún beneficio de invalidación. SwiftUI igual vuelve a ejecutar la propiedad cada vez que vuelve a ejecutar body, así que el movimiento es una ganancia de legibilidad y nada más.²⁰ La frontera de rendimiento aparece un nivel más arriba: extrae un tipo de vista separado y SwiftUI puede invalidarlo de forma independiente, volviendo a ejecutar solo esa vista cuando sus entradas cambian en lugar de todo el body que la contiene. Recurre a una nueva vista, no a una nueva propiedad, cuando quieres que SwiftUI haga menos trabajo.

Cada cambio de entorno invalida todas las vistas que leen ese valor del entorno. Leer el entorno es barato; la rotación del entorno no lo es.²¹ Mantén los valores que cambian rápido fuera del entorno (el ejemplo del panel es la hora actual), porque un valor que se actualiza cada frame arrastra a cada lector a una reevaluación cada vez que se mueve. Pasa los valores volátiles por la ruta que los necesita y deja que el entorno cargue las cosas que se quedan quietas.

Una sesión de lab posterior agrega tres detalles de mecanismo más, todos parafraseados a partir de una grabación transcrita localmente del SwiftUI Group Lab de la WWDC 2026, para el cual Apple no publica subtítulos oficiales.

La evaluación parcial del grafo explica adónde va realmente el trabajo precargado. El panel describió un lazy stack evaluando los body de las celdas próximas en el tiempo de frame que queda después de que el frame actual se renderiza, y luego deteniéndose justo antes de que comience el siguiente frame.²² El detalle que señalaron: un onAppear que reconfigura una celda de modo que haya que hacerle el layout de nuevo, porque cambia el tamaño de la celda, descarta ese trabajo precargado. Su orientación fue hacer el trabajo de dimensionamiento en el inicializador de la celda, no en body ni en onAppear, para que el prefetch sobreviva.²²

El modelo mental de la interoperabilidad vino de un panelista con más de una década en UIKit. UIKit hace el layout de arriba hacia abajo, desde la ventana hacia adentro hasta las hojas, mientras que SwiftUI construye de abajo hacia arriba, desde el nodo más interno hacia afuera.²² Cuando los dos se entrelazan, el panel llamó a la disposición de capas alternadas un sándwich o un pastel, que es la razón por la que el entrelazado profundo se vuelve sutil: cada framework quiere conducir el pase de layout desde el extremo opuesto.²²

El punto sobre el entorno de arriba obtuvo un ejemplo vívido del mundo real. Cuando se les preguntó por el peor mal uso del entorno que habían visto, el panel citó poner la posición de scroll en el entorno, que se actualiza en cada frame mientras se hace scroll y por lo tanto invalida a cada lector en cada frame.²²

Una segunda sesión del SwiftUI Group Lab agregó cuatro detalles de mecanismo más, todos parafraseados a partir de una grabación transcrita localmente del SwiftUI Group Lab de la WWDC 2026 (sesión 2); Apple no publica subtítulos oficiales para los labs.

El modificador onGeometryChange(for:of:action:) se lee mejor de lo que suena por cómo sus dos clausuras dividen el trabajo. La clausura de transformación se ejecuta con geometría en vivo en cada frame, pero solo el valor que devuelve determina si la acción se dispara, ya que el tipo del resultado es Equatable y la acción se ejecuta solo cuando ese valor cambia.²³ Así que devolver un valor grueso (un bucket de tamaño o un breakpoint de layout, no el tamaño crudo) convierte una señal de tasa de frames en una que se dispara dos veces, en los umbrales, en lugar de continuamente. El panel emparejó esto con una advertencia de que GeometryReader es costoso para las subvistas que envuelve y debería confinarse a un background para que mida sin conducir el layout principal.²³

Una buena dynamic property puede reemplazar la mayor parte del trabajo de onChange por completo. El método update() de un DynamicProperty se ejecuta inmediatamente antes del body de la vista, así que un property wrapper personalizado puede entregar un valor ya cacheado (el ejemplo del panel fue una imagen) de forma síncrona en ese punto y saltarse el viaje de ida y vuelta de onAppear y el re-render que dispara.²⁴ El planteamiento del panel fue que la mayoría de los usos de onChange pueden reemplazarse por una dynamic property bien construida.²⁴

Una vista que dibuja fuera de los límites de layout que reporta dentro de un ScrollView puede ser descartada (culled), porque el sistema decide que está fuera de pantalla a partir de los límites que se le dijeron, no de dónde realmente pinta.²⁵ El panel nombró esto como el comportamiento de falla concreto detrás de dropdowns y overlays personalizados que desbordan su vista anfitriona y luego se desvanecen a mitad del scroll, y señaló que el mismo riesgo se aplica al contenido de overlay que se extiende más allá de su ancla.²⁵

Presentar un overlay de pantalla completa por encima de todo, incluidos los sheets, no tiene una respuesta limpia puramente en SwiftUI. La orientación del panel fue bajar a un nuevo UIWindow a través del ciclo de vida basado en escenas de UIKit, con el principio más profundo de que la última ventana gana y debe haber una única fuente de verdad para lo que se ubica encima.²⁶ Agregaron que la mejor solución a menudo es restaurar el navigation stack que el usuario espera en lugar de arrojar una cubierta disruptiva por encima de todo.²⁶

Qué adoptar primero

Un lanzamiento explicado como mecanismo premia ordenar por apalancamiento, no por novedad.

1. Cambia las clases de modelo a @Observable en tu código de AppKit/UIKit. Elimina las llamadas manuales a needsDisplay, da a cada método de dibujo y layout que observa redibujado automático, y es el prerrequisito que hace trivial un futuro drop-in de NSHostingView.⁸¹⁴ Es el movimiento de menor riesgo y mayor recompensa inmediata de las tres sesiones.
2. Audita los lazy stacks en busca de conteos de subvistas dinámicos. Cualquier hoja de ForEach que devuelva condicionalmente cero o una subvista, o desempaque un opcional en su body, está manteniendo vivas las vistas por índice; mueve el filtro a un Predicate sobre un Query (o más arriba en la jerarquía) y tanto la memoria como el rendimiento de scroll-to-item mejoran.¹
3. Mueve la configuración de la vista fuera de onAppear y hacia los inicializadores. El prefetching solo ayuda si el trabajo precargado sobrevive; una configuración que muta el tamaño o el contenido en onAppear descarta ese trabajo.¹ Esta es una ganancia silenciosa y amplia de fluidez del scroll.
4. Reemplaza las lecturas absolutas de offset de scroll por APIs de visibilidad relativa. Cualquier cosa ligada al offset de contenido irá a la deriva; .onScrollTargetVisibilityChange se liga a qué filas están realmente visibles.²¹
5. Recurre a los shaders solo donde un efecto pequeño se gane su lugar. Empieza en colorEffect o distortionEffect; escala a layerEffect solo cuando un efecto deba muestrear vecinos, e impulsa cualquier movimiento con una marca de tiempo de un TimelineView en lugar de esperar estado dentro del shader.⁴⁵⁶⁷

El hilo conductor a través de las tres: predice el framework antes de empujarlo. Los lazy stacks estiman, los shaders olvidan, y la interoperabilidad es una costura, no una reescritura. Construye con esos tres hechos en mente y el resto se desprende.

Preguntas frecuentes

¿Por qué la posición de scroll de mi lazy stack de SwiftUI salta o va a la deriva?

Porque un LazyVStack no carga las vistas fuera de pantalla, estima sus alturas y el espacio por encima de la región visible, así que el offset absoluto de contenido es una estimación que el framework corrige a medida que aprende el layout real (después de un cambio de orientación, por ejemplo, reconcilia la estimación cuando haces scroll de vuelta hacia arriba).¹ Si ligas la UI al offset absoluto, el umbral va a la deriva a medida que las estimaciones se asientan. Usa .onScrollTargetVisibilityChange, que se dispara según qué subvistas están realmente visibles, en su lugar.²

¿Cómo mantengo el scroll fluido en un lazy stack de SwiftUI en iOS 27?

Deja que el prefetching haga su trabajo: configura las vistas en su inicializador para que el trabajo que el lazy stack realiza antes de que una vista aparezca no se descarte, y evita mutar el tamaño o el contenido de una vista en onAppear.¹ Además evita una cantidad dinámica de subvistas en las hojas de ForEach y evita cambios de layout (como una altura impulsada por onGeometryChange) después de que una vista aparezca, ya que ambos fuerzan al stack a rehacer trabajo o recalcular posiciones a mitad del scroll.¹

¿Cuándo debería usar colorEffect, distortionEffect o layerEffect?

Usa colorEffect para transformar el color de cada píxel a partir de su posición y su color original (un filtro de escala de grises, por ejemplo).⁴ Usa distortionEffect para efectos geométricos, donde mapeas una posición de salida a una posición de origen desde la cual muestrear.⁵ Usa layerEffect cuando el píxel de salida depende de más de un píxel de entrada, porque le da al shader la capa entera de la vista para muestrear vecinos o la región completa, que es lo que necesitan el blur y el domain warping.⁶

¿Cómo animo un shader de Metal en SwiftUI?

Los shaders no tienen estado: no guardan memoria del frame anterior y dependen solo de sus parámetros, así que no puedes animar desde dentro del shader.³ Inyecta un valor que cambie con el tiempo. Un TimelineView en un schedule de animación se dispara cada frame con una marca de tiempo; pasa esa marca de tiempo al shader como parámetro (la sesión la suma a la posición de muestreo del ruido) y el efecto se anima.⁷³

¿Puedo agregar SwiftUI a una app existente de AppKit o UIKit sin reescribirla?

Sí, y la sesión es explícita en que ninguna app necesita ser enteramente SwiftUI para beneficiarse.⁸ Marca tu modelo como @Observable para que AppKit y UIKit redibujen automáticamente, luego incrusta vistas de SwiftUI con NSHostingView, trae los gesture recognizers existentes con NSGestureRecognizerRepresentable, construye menús con NSHostingMenu, y adjunta escenas de SwiftUI desde tu app delegate con NSHostingSceneRepresentation; todos estos se incluyen en los lanzamientos de 2026 o anteriores.^816171819

El cluster completo de Apple Ecosystem: el sustrato de SwiftUI (result builders, tipos opacos, el árbol de vistas tipado por valor) que explica por qué un lazy stack resuelve los structs de vista en un conjunto diferente de subvistas; la superficie de SwiftUI en iOS 27 (reordenamiento, documentos, toolbars, errores) junto a la que se sitúa esta historia de rendimiento e interoperabilidad; los internals de @Observable que ahora impulsan el redibujado automático también en AppKit y UIKit; y los patrones de Liquid Glass cuya implementación entre frameworks la sesión de interoperabilidad atribuye a SwiftUI compartido. El hub es la Serie Apple Ecosystem. Para un contexto más amplio de iOS con agentes de IA, consulta la guía de Desarrollo de Agentes en iOS.

Referencias