Here is a blog post written specifically for My Core Pick.
Deja de escribir el mismo código dos veces: Compartiendo la lógica de negocio con Kotlin Multiplatform
Levanta la mano si alguna vez has arreglado un bug en la versión Android de tu aplicación, solo para darte cuenta tres semanas después de que el mismo bug sigue aterrorizando a tus usuarios de iOS.
Todos hemos pasado por eso.
Es la clásica lucha del desarrollo móvil. Tienes dos bases de código. Tienes dos equipos (o un freelancer muy cansado). Tienes dos lenguajes.
Pero tienes un solo producto.
Durante años, la solución de la industria para esto fueron los frameworks "Híbridos". Probamos PhoneGap. Luchamos con React Native. Coqueteamos con Flutter.
Si bien esas herramientas son excelentes, a menudo te piden que comprometas la Interfaz de Usuario (UI). Tienes que reconstruir la apariencia desde cero en su ecosistema.
Pero, ¿qué pasa si quieres mantener tu UI nativa? ¿Qué pasa si amas SwiftUI y Jetpack Compose?
¿Qué pasa si solo quieres compartir los "cerebros" de la aplicación, no la cara?
Entra Kotlin Multiplatform (KMP).
Aquí en My Core Pick, creemos en trabajar de manera más inteligente, no más dura. Hoy, te voy a mostrar por qué KMP es el futuro para compartir lógica de negocio y cómo evita que te repitas.
La trampa de la "Doble Plataforma"
Hablemos del problema antes de sumergirnos en la solución.
Cuando construyes una aplicación nativa para iOS y Android, no solo estás escribiendo la UI dos veces.
Estás escribiendo todo dos veces.
Escribes la capa de red en Swift y en Kotlin.
Escribes la lógica de base de datos en CoreData y Room.
Escribes la lógica de validación de datos (¿es válido este correo electrónico?) en dos archivos diferentes.
Esta es la definición de redundancia.
No se trata solo del tiempo que lleva escribir el código inicialmente. El verdadero dolor viene después.
Viene durante el mantenimiento.
Si cambias una regla de negocio en Android, debes recordar cambiarla en iOS. Si no lo haces, tu aplicación se comporta de manera inconsistente.
Los usuarios notan esto. Puede que no sepan por qué, pero la aplicación se siente "rara".
Esta duplicación aumenta la superficie para bugs. Duplica tus requisitos de prueba. Duplica tu carga cognitiva.
Tiene que haber una mejor manera de manejar la capa lógica.
¿Qué es exactamente Kotlin Multiplatform?
Kotlin Multiplatform no es un framework en el sentido tradicional.
No es una caja negra de "escribe una vez, ejecuta donde sea" que renderiza un canvas en tu pantalla.
KMP es un SDK diseñado para compartir código entre plataformas.
Compila código Kotlin en bytecode de JVM para Android. Esa es la parte fácil.
Pero la magia es que compila el mismo código Kotlin en bytecode de LLVM para iOS. Esto significa que se ejecuta nativamente en el hardware de Apple.
Para Xcode, tu código Kotlin compartido simplemente parece un framework de Objective-C.
Puedes importarlo, llamar funciones y leer datos tal como lo harías con cualquier otra biblioteca nativa.
La filosofía aquí es simple: Lógica compartida, UI nativa.
Mantienes tus hermosas vistas en SwiftUI. Mantienes tus diseños performantes en Jetpack Compose.
Simplemente dejas de escribir el código que los impulsa dos veces.
¿Qué deberías compartir realmente?
Cuando comencé con KMP, intenté compartir todo.
Eso fue un error.
El poder de KMP proviene de saber dónde trazar la línea. No deberías intentar compartir tus botones, animaciones o transiciones de navegación.
Deberías compartir la Lógica de Negocio.
Entonces, ¿cómo se ve eso en la práctica? Aquí están los tres pilares principales en los que nos enfocamos.
1. La capa de datos
Este es el objetivo más fácil.
Toda aplicación necesita hablar con internet. Toda aplicación necesita analizar JSON.
En una configuración tradicional, tienes structs Codable en Swift y Data Classes en Kotlin. Si el backend cambia, tienes que actualizar ambos.
Con KMP, escribes tus modelos de datos una vez.
Usas una biblioteca como Ktor para la red y Kotlin Serialization para el análisis.
Escribes una clase repositorio que obtiene los datos, los analiza y maneja los errores.
Tanto tu aplicación iOS como Android simplemente llaman a repository.getData(). No les importa cómo llegan los datos allí. Simplemente los muestran.
2. Almacenamiento Local
La gestión de bases de datos es compleja.
Gestionar migraciones en dos plataformas diferentes es una pesadilla.
Con KMP, usamos bibliotecas como SQLDelight o Room (que ahora soporta KMP).
Defines tu esquema de base de datos en un solo lugar. Escribes tus consultas SQL en un solo lugar.
El código generado maneja los drivers específicos de la plataforma.
Tu aplicación Android usa el driver de SQLite. Tu aplicación iOS usa el driver Nativo.
La lógica que gobierna cómo guardas, recuperas y eliminas datos de usuario permanece idéntica en ambas plataformas.
3. Los "Cerebros" (ViewModels)
Aquí es donde las cosas se ponen realmente emocionantes.
De hecho, puedes compartir tus ViewModels.
El ViewModel es el componente que mantiene el estado de tu pantalla. Decide qué sucede cuando un usuario hace clic en un botón. Decide qué mostrar cuando falla la red.
Esto es lógica pura. No tiene nada que ver con píxeles.
Al compartir el ViewModel, tu UI se vuelve increíblemente "tonta" — lo cual es algo bueno.
Tu vista de SwiftUI simplemente observa un objeto de estado desde el código compartido de Kotlin.
Si el estado dice isLoading = true, la UI muestra un indicador de carga.
La UI no necesita saber por qué está cargando. Solo sigue órdenes.
Cómo funciona: Un vistazo técnico
Sé lo que estás pensando.
"Esto suena genial, pero ¿es la configuración una pesadilla?"
Solía serlo. Pero el ecosistema ha madurado masivamente en el último año.
Miremos la estructura del proyecto.
Los Source Sets (Conjuntos de fuentes)
Un proyecto KMP se divide en "Source Sets".
Primero, tienes commonMain.
Aquí es donde vive el 90% de tu código. Esto es Kotlin puro. Contiene tus modelos, repositorios y lógica.
Luego, tienes androidMain e iosMain.
Estas carpetas son para código específico de la plataforma.
Si estás escribiendo un algoritmo puro, va en commonMain.
Pero a veces, necesitas acceder a una característica específica del dispositivo, como la Cámara o el Bluetooth.
Kotlin no sabe cómo acceder a la cámara de iOS por defecto.
El mecanismo Expect/Actual
Este es el puente entre el mundo compartido y el mundo nativo.
Actúa como una Interfaz, pero a nivel de lenguaje.
En tu carpeta commonMain, podrías escribir:
expect fun getPlatformName(): String
El compilador ahora se quejará. Te dirá que prometiste una función, pero no has proporcionado la implementación.
Entonces, en androidMain, escribes:
actual fun getPlatformName(): String = "Android"
Y en iosMain, escribes:
actual fun getPlatformName(): String = UIDevice.currentDevice.systemName()
Nota que en iosMain, puedo acceder a UIDevice. Esa es una API de Apple.
Puedo acceder a ella directamente dentro de Kotlin porque KMP tiene acceso a los SDKs de iOS.
Este mecanismo te permite compartir lógica de alto nivel mientras sigues accediendo a capacidades nativas siempre que lo necesites.
Los beneficios en el mundo real
Implementamos KMP en un proyecto reciente en My Core Pick.
Los resultados cambiaron mi forma de ver el desarrollo móvil.
La consistencia es el rey
El mayor beneficio no fue la velocidad. Fue la consistencia.
Teníamos un cálculo complejo para un "Puntaje de Salud" en la aplicación.
En el pasado, el desarrollador de iOS interpretaba los requisitos de una manera, y el desarrollador de Android de otra. Terminábamos con puntajes ligeramente diferentes para los mismos datos.
Con KMP, escribimos el algoritmo una vez.
Hicimos pruebas unitarias intensivas en Kotlin.
Lo desplegamos.
Sabíamos con certeza que si un usuario cambiaba de dispositivo, su puntaje sería exactamente el mismo.
Iteración de funcionalidades más rápida
Una vez que la arquitectura estuvo establecida, agregar nuevas funcionalidades se volvió significativamente más rápido.
Cuando necesitábamos agregar un nuevo endpoint de API, lo añadíamos en el módulo compartido.
De repente, tanto los desarrolladores de iOS como los de Android tenían acceso a él al instante.
No teníamos que esperar a que el desarrollador de iOS se pusiera al día con la capa de red.
Crea una dinámica de "carrera de relevos". El desarrollador de lógica central despeja el camino, y los desarrolladores de UI corren hacia la línea de meta.
Pruebas supercargadas
Probar la UI es difícil. Probar la lógica de negocio es (relativamente) fácil.
Debido a que nuestra lógica está separada del SO, podemos ejecutar nuestras pruebas en la JVM.
Esto es increíblemente rápido. No necesitamos lanzar un Emulador de Android o un Simulador de iOS para probar nuestros ViewModels.
Escribimos pruebas JUnit estándar. Se ejecutan en milisegundos.
Esto nos anima a escribir más pruebas, lo que conduce a un producto más estable.
¿Está listo para las grandes ligas?
Podrías dudar en adoptar una nueva tecnología.
Ese es un escepticismo saludable.
Sin embargo, KMP es utilizado por gigantes.
Netflix lo usa. VMWare lo usa. McDonald's lo usa.
Google lo soporta oficialmente.
El ecosistema de bibliotecas está prosperando.
Para Inyección de Dependencias, tenemos Koin.
Para Redes, tenemos Ktor.
Para Logging, tenemos Napier.
Las herramientas están ahí. El soporte está ahí.
Conclusión
Estamos en una nueva era del desarrollo móvil.
Los días de aislar estrictamente la lógica de iOS y Android están terminando. Simplemente cuesta demasiado dinero y tiempo.
Pero tampoco estamos dispuestos a sacrificar la calidad de las UIs nativas.
Kotlin Multiplatform da en el punto ideal.
Respeta las diferencias de plataforma donde importa (la UI) y unifica las similitudes de plataforma donde cuenta (la lógica).
Deja de escribir el mismo código dos veces.
Deja de arreglar el mismo bug dos veces.
Empieza a compartir tu lógica de negocio. Tu base de código (y tu cordura) te lo agradecerán.
¿Disfrutaste esta inmersión profunda? Echa un vistazo a más conocimientos técnicos justo aquí en My Core Pick.