Qué construimos con él
Kotlin Multiplatform hace la apuesta contraria a Flutter. En lugar de compartir la app entera incluida su UI, compartes solo las partes que no tienen por qué escribirse dos veces —red, modelos, validación, persistencia, reglas de negocio— y cada plataforma construye su propia interfaz en SwiftUI o Jetpack Compose.
El código compartido es Kotlin, compilado a un framework nativo en iOS y a Kotlin normal en Android. Desde el lado de iOS es simplemente una librería.
Dónde encaja
En productos con apps nativas y equipos nativos ya existentes. Ese es el caso en el que KMP es genuinamente bueno: puedes mover un módulo —el cliente de API, la caché offline— a código compartido sin reescribir ninguna de las dos apps ni pedirle a nadie que renuncie a su plataforma.
También encaja en productos donde la UI tiene que ser tan nativa que un renderizador multiplataforma es un lastre, pero donde la lógica de dominio por debajo es idéntica.
Cuándo lo recomendamos
Cuando ya tienes dos bases de código nativas y quieres dejar de mantener la misma lógica dos veces, o cuando la interfaz realmente tiene que construirse de forma nativa en ambas plataformas de todos modos.
No para un producto que empieza de cero con un solo equipo. Ahí, KMP significa escribir la UI dos veces —la mitad cara— y has asumido una cadena de herramientas multiplataforma sin el ahorro que la justifica. Flutter suele ser el mejor cambio, y lo diremos.
Sé honesto también con el lado iOS: depurar Kotlin compartido desde Xcode es viable pero no agradable, y el tooling es notablemente más joven que el de Flutter.
