Kotlin Multiplatform Mobile — qué es, conceptos clave y arquitectura de KMM

¿Qué es Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) es una tecnología que permite escribir la lógica de negocio compartida de una aplicación móvil en Kotlin y usarla en iOS y Android sin duplicar código. A diferencia de Ionic o Cordova, KMM no renderiza la interfaz en un WebView: la interfaz de usuario permanece completamente nativa y se escribe en SwiftUI (iOS) y Jetpack Compose (Android).

KMM fue anunciado por JetBrains en 2019 como parte de la estrategia Kotlin Multiplatform. La diferencia clave con otras soluciones multiplataforma es que el framework no intenta unificar la interfaz de usuario, sino que se centra en compartir precisamente el código que es realmente idéntico para ambas plataformas: solicitudes de red, modelos de datos, validación de formularios, reglas de negocio y operaciones con bases de datos.

Según la Encuesta para Desarrolladores de JetBrains (2025), KMM es utilizado por el 14% de los desarrolladores móviles, y esta cifra crece un 5% anual. La tecnología es elegida por empresas con altas exigencias de rendimiento y experiencia de usuario nativa, donde las soluciones híbridas no son aceptables.

Arquitectura de KMM: módulo compartido e implementaciones de plataforma

La arquitectura de KMM consta de tres módulos: shared (código común en Kotlin), iosApp (aplicación nativa de iOS en Swift) y androidApp (aplicación nativa de Android en Kotlin). El módulo compartido se compila en un JAR para Android y en un framework universal (Apple Framework) para iOS.

Módulo compartido: qué se incluye en el código común

El módulo compartido contiene todas las capas independientes de la plataforma: la capa de red con Ktor Client, modelos de datos con serialización mediante kotlinx.serialization, repositorios para la gestión de datos, validación de formularios y reglas de negocio (por ejemplo, calcular el costo de envío o verificar permisos de acceso).

El módulo compartido utiliza el Plugin Gradle Multiplatform y contiene tres conjuntos de código fuente: commonMain (código común), androidMain (implementaciones específicas de Android) e iosMain (implementaciones específicas de iOS). El compilador Kotlin/Native transforma el código común en una biblioteca nativa para iOS, que se vincula al proyecto Swift a través de XCFramework.

Módulos de plataforma

Módulo Android — es una aplicación estándar de Android en Kotlin con Jetpack Compose o ViewBinding. El módulo compartido se conecta como una dependencia normal de Gradle, y todas las clases de commonMain son directamente accesibles.

El módulo iOS es un proyecto de Xcode en Swift u Objective-C. El módulo compartido se conecta a través de CocoaPods, Swift Package Manager o XCFramework. Kotlin/Native genera cabeceras Objective-C para exportar tipos de Kotlin, haciéndolos accesibles desde Swift.

El mecanismo expect/actual en KMM

expect/actual es un mecanismo de Kotlin Multiplatform que permite declarar una API en código compartido (declaración expect) y proporcionar su implementación por separado para cada plataforma (declaración actual). El compilador se asegura de que exista una declaración actual para cada plataforma objetivo.

Casos de uso típicos de expect/actual: obtener la hora actual con zona horaria, trabajar con SharedPreferences (Android) / UserDefaults (iOS), funciones criptográficas y generación de UUID. Cada plataforma utiliza su propia API del sistema.

Sin expect/actual, sería imposible tener un código unificado de lógica de negocio, ya que las API para trabajar con el sistema de archivos, la red y el almacenamiento difieren entre iOS y Android a nivel de llamadas del sistema. El mecanismo garantiza que el desarrollador no olvide implementar la parte específica de la plataforma.

Para llamadas de plataforma como trabajar con la cámara o la biometría, KMM ofrece el mecanismo expect/actual combinado con plugins similares a Cordova, pero en Kotlin/Native. JetBrains también ha lanzado la biblioteca kotlinx-datetime, que abstrae el manejo de fechas y horas.

Ejemplos de código en KMM

Veamos la estructura básica de un proyecto KMM con la declaración de una función expect para la generación de UUID y su implementación para iOS y Android.

// commonMain — declaración común
expect fun generateUUID(): String

// androidMain — implementación para Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — implementación para iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

En el código común se declara expect fun generateUUID(). Android usa java.util.UUID, mientras que iOS usa NSUUID del framework Foundation. En el resto del código del módulo compartido, esta función se llama sin tener en cuenta la plataforma.

Un ejemplo de solicitud de red usando Ktor Client en código común:

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

Este código funciona en ambas plataformas sin cambios. Ktor Client usa OkHttp en Android y NSURLSession en iOS automáticamente, sin configuración adicional. La serialización JSON a través de kotlinx.serialization también es multiplataforma.

Comparación de KMM con Flutter y React Native

KMM ocupa una posición única entre las tecnologías multiplataforma, ya que no intenta reemplazar la interfaz nativa a diferencia de Flutter y React Native. KMM es una solución para compartir lógica, no para unificar la interfaz.

La principal ventaja de KMM es el control total sobre la interfaz de usuario. Si una aplicación debe verse y comportarse de forma nativa en cada plataforma (por ejemplo, usando la TabBar de iOS y la BottomNavigation de Android con animaciones de plataforma), KMM es la única solución multiplataforma que lo proporciona sin soluciones improvisadas.

La desventaja es que el equipo debe conocer Kotlin, Swift, Jetpack Compose y SwiftUI simultáneamente, lo que complica la contratación. Flutter y React Native requieren el conocimiento de un solo lenguaje y un solo framework.

Ventajas y desafíos de adoptar KMM

Kotlin Multiplatform Mobile es una tecnología potente, pero su adopción requiere un enfoque equilibrado. Examinemos las ventajas clave y los desafíos típicos a los que se enfrentan los equipos.

Ventajas de KMM

La primera y principal ventaja es la reducción de la duplicación de código. Según los Casos de Estudio de JetBrains (2024), los equipos que adoptaron KMM reducen el código duplicado en un 60–80% para la capa de red y en un 40–50% para la lógica de negocio en general. Esto impacta directamente en la velocidad de desarrollo y en la cantidad de errores.

La segunda ventaja es el rendimiento al nivel de las aplicaciones nativas. A diferencia de los frameworks híbridos, KMM no añade capas de abstracción entre la interfaz de usuario y el sistema. El código de la lógica de negocio se ejecuta tan rápido como si estuviera escrito en Swift o Kotlin para cada plataforma por separado.

Desafíos de la adopción

El principal desafío es la cualificación del equipo. Los desarrolladores deben conocer Kotlin (para el módulo compartido), así como Swift y Jetpack Compose (para la interfaz de usuario). Encontrar un especialista universal es difícil, por lo que los equipos suelen estar formados por desarrolladores de Android e iOS que mantienen conjuntamente el módulo compartido.

El segundo desafío son las herramientas. KMM requiere configurar Gradle, CocoaPods o Swift Package Manager, así como la integración con Xcode. En las primeras etapas de un proyecto, los problemas de configuración de compilación son comunes, especialmente al trabajar con bibliotecas C.

El tercer desafío es la depuración. Cuando ocurre un error en la intersección de Kotlin/Native y Swift, determinar su causa es más difícil que en una aplicación monolítica. JetBrains mejora continuamente las herramientas de depuración, pero en la práctica, los equipos dedican hasta el 20% de su tiempo a tareas de infraestructura.