Qué construimos con él
Swift es donde nuestras apps Flutter se encuentran con iOS de verdad. La capa multiplataforma se hace cargo de casi todo un producto, pero no de las partes que viven en el sistema operativo: ejecución en segundo plano, extensiones de servicio de notificaciones, keychain y biometría, NFC, SDKs de proveedores distribuidos como frameworks nativos y todo lo que tenga que aparecer fuera de la propia app.
Ese trabajo se escribe en Swift detrás de un platform channel, de modo que el lado Dart ve una API limpia y ningún detalle del ciclo de vida de iOS. Es el equivalente exacto de lo que hace Kotlin en Android, y una integración de plataforma suele implicar escribir ambos.
Dónde encaja
Dentro de nuestros proyectos Flutter y no al lado, así que no aparece como una entrada propia del portfolio. Surge allí donde el código multiplataforma no llega; por ejemplo, la mitad de App Clip del trabajo de deep linking diferido sobre el que hemos escrito, que no tiene implementación portable.
Los widgets de pantalla de inicio, las extensiones de compartir y las superficies de SwiftUI son el otro caso habitual: son targets separados en los que un motor de Flutter no se ejecuta.
Cuándo lo recomendamos
Para la mitad iOS de una integración de plataforma, y para una app iOS completamente nativa cuando el producto es genuinamente específico de la plataforma: integración profunda con el sistema, un público exclusivo de Apple o un equipo ya invertido ahí.
No como opción por defecto para un producto que también necesita Android. Dos bases de código nativas significan dos equipos, dos ciclos de release y dos conjuntos de bugs; salvo que algo lo obligue, Flutter con una capa de Swift debajo te da la misma capacidad por bastante menos.
