Qué construimos con él
Hay superficies de iOS en las que un motor de Flutter sencillamente no se ejecuta, y SwiftUI es como las construimos. Widgets de pantalla de inicio y de bloqueo, Live Activities, App Clips, extensiones de compartir y de notificaciones, apps de reloj: cada una es un target separado con su propio proceso y su propia UI, y cada una tiene que escribirse de forma nativa.
Declarativo y guiado por estado, SwiftUI está conceptualmente cerca de Flutter, y eso importa en la práctica: un ingeniero que se mueve entre ambos piensa con las mismas formas en lugar de reaprender los view controllers imperativos de UIKit.
Dónde encaja
Alrededor de una app Flutter y no en su lugar, escrito en Swift y compartiendo datos con la app principal a través de un app group. El trabajo con App Clips sobre el que hemos escrito tiene exactamente esta forma: una pequeña experiencia nativa que se lanza sin instalación y traspasa a la app completa.
Cuándo lo recomendamos
Para esos targets de extensión, donde no hay alternativa, y para apps iOS completamente nativas cuando el producto es solo de Apple.
No para la UI principal de un producto multiplataforma. Construir la interfaz primaria dos veces —SwiftUI en iOS y otra cosa en Android— es el coste que Flutter existe para eliminar, y hacer ambas significa que cada pantalla se diseña, se construye y se arregla dos veces.
Conviene saberlo: SwiftUI todavía tiene huecos que te devuelven a UIKit para controles concretos, y su comportamiento cambia de forma apreciable entre versiones de iOS. Es lo bastante maduro como para construir sobre él, no como para darlo por hecho.
