En el artículo anterior de la serie (Unidad 0 — Tema 3), desmitificamos la asincronía en Kotlin a través de las corrutinas, los despachadores y los ámbitos de ejecución estructurada. Sin embargo, procesar una única llamada de red de forma asíncrona es solo el principio.

Si echamos la vista atrás, la forma en que manejamos la asincronía y la reactividad ha cambiado drásticamente. Atrás quedaron los tiempos de RxJava con sus complejas cadenas de operadores, e incluso LiveData ha pasado a formar parte del baúl de los recuerdos de Android.

Hoy, en 2026, la API de Kotlin Flows es el estándar indiscutible. Cuando trabajamos en Kotlin Multiplatform (KMP), los flujos reactivos no son solo una opción para el módulo de Android; son la herramienta nativa con la que comunicamos la lógica de negocio compartida con las interfaces de usuario de Jetpack Compose y SwiftUI.

Para dominar la arquitectura multiplataforma, necesitas entender a los dos reyes del flujo «caliente»: StateFlow y SharedFlow.

1. El concepto clave: Flujos Fríos vs. Flujos Calientes

Antes de entrar en detalle, una distinción rápida pero vital:

• Flujos Fríos (Flow estándar): Solo emiten datos cuando alguien los está escuchando (collecting). Si hay tres observadores, la ejecución se repite tres veces desde el principio para cada uno. Son ideales para consultas a bases de datos o peticiones de red únicas.
• Flujos Calientes (StateFlow / SharedFlow): Están activos y emitiendo datos independientemente de si hay pantallas escuchando o no. Son como estaciones de radio: la música sigue sonando aunque apagues el auto. Múltiples observadores pueden sintonizar el mismo flujo al mismo tiempo.

2. La Batalla Definitiva: StateFlow vs. SharedFlow

Aunque ambos son flujos calientes, tienen propósitos arquitectónicos completamente opuestos. Confundirlos suele provocar bugs visuales extraños.

Característica	StateFlow	SharedFlow
Propósito	Representar un Estado (¿Cómo se ve la pantalla?).	Representar un Evento (¿Qué acaba de pasar?).
Valor Inicial	Obligatorio. Siempre debe empezar con un estado.	No lo requiere.
Memoria (Replay)	Almacena y repite siempre el último valor emitido.	Por defecto no almacena nada (configurable).
Filtrado	Descarta duplicados consecutivos (distinctUntilChanged).	Emite absolutamente todo, incluso si es idéntico.

3. Lógica Compartida en KMP: Un caso práctico

Imaginemos un componente de lógica compartida (un ViewModel o Presenter común) que gestiona el estado de un perfil y dispara una alerta de un solo uso (como un mensaje flotante o Toast).

class PerfilViewModel {
    // 1. STATEFLOW: Guarda el estado de la pantalla
    private val _uiState = MutableStateFlow<PerfilState>(PerfilState.Loading)
    val uiState: StateFlow<PerfilState> = _uiState.asStateFlow()

    // 2. SHAREDFLOW: Dispara eventos únicos que no deben repetirse si la pantalla gira
    private val _eventos = MutableSharedFlow<PerfilEvent>()
    val eventos: SharedFlow<PerfilEvent> = _eventos.asSharedFlow()

    suspend fun actualizarNombre(nuevoNombre: String) {
        if (nuevoNombre.isBlank()) {
            // El error es un evento. Se muestra una vez y listo.
            _eventos.emit(PerfilEvent.MostrarError("El nombre no puede estar vacío"))
            return
        }
        
        _uiState.value = PerfilState.Success(nombre = nuevoNombre)
    }
}

💡 Por qué esto es crucial: Si usaras un StateFlow para el mensaje de error, cuando el usuario rote el teléfono, la pantalla volvería a leer el último estado guardado y mostraría el mensaje de error otra vez, frustrando al usuario. Con SharedFlow, el evento se consume y desaparece.

4. El consumo multiplataforma: Conectando con las Vistas

Escribir el flujo en Kotlin es solo la mitad del trabajo. ¿Cómo se consumen en las plataformas de destino?

En Android (Jetpack Compose)

Compose se integra de manera orgánica con los flujos de Kotlin. Usando la extensión adecuada, la recolección se detiene automáticamente cuando la app pasa a segundo plano, ahorrando batería:

val state by viewModel.uiState.collectAsStateWithLifecycle()

En iOS (SwiftUI)

En el desarrollo multiplataforma moderno, consumir estos flujos desde Swift ya no requiere acoplamientos complejos (wrappers) manuales.

Herramientas de interoperabilidad como SKIE convierten automáticamente tus StateFlow de Kotlin en propiedades nativas que exponen objetos de tipo AsyncSequence o AsyncStream en Swift. Para un desarrollador de iOS, interactuar con tu lógica reactiva se siente idéntico a usar Async/Await nativo de Apple:

Task {
    for await state in viewModel.uiState {
        self.render(state)
    }
}

5. Enfoque Sénior: Prevención de fugas de recursos en iOS al recolectar flujos

Recolectar flujos reactivos de Kotlin en Swift a través de AsyncSequence es una gozada, pero introduce un riesgo severo de fugas de memoria y consumo de batería residual si la suscripción no se cancela al salir de la pantalla:

• El ciclo de vida en SwiftUI: En Android, collectAsStateWithLifecycle() detiene la recolección automáticamente cuando la vista pasa a STOPPED. En SwiftUI, debes asociar la recolección asíncrona al modificador .task { } de SwiftUI. Este modificador cancela la Task de Swift automáticamente cuando la vista se destruye o se desmonta del árbol visual.
• Suscripciones calientes persistentes: Si inicias una recolección manual de un StateFlow o SharedFlow de fondo y olvidas desvincularla, el recolector de basura de Kotlin (GC) no podrá liberar la instancia de la clase compartida debido a una referencia fuerte sostenida por la clausura de Swift.
• Buenas prácticas: Declara siempre tus flujos compartidos en componentes vinculados al ciclo de vida de los controladores de vista y utiliza en Swift llamadas estructuradas ligadas al ciclo de vida visual de SwiftUI para evitar fugas silenciosas.

Para profundizar

La programación reactiva con flujos tiene reglas estrictas de concurrencia. Te sugiero revisar la documentación oficial para profundizar en operadores avanzados y testing:

• Documentación oficial de Kotlin Flows: Conceptos base, operadores de transformación y flujos fríos.
• StateFlow y SharedFlow en detalle: Especificaciones técnicas de la librería kotlinx.coroutines sobre flujos calientes.
• SKIE y el soporte para Kotlin Flows: Cómo funciona la magia de la traducción automática de Flows a AsyncSequence en Swift.

Conclusión

Diseñar tu arquitectura multiplataforma basándote en la combinación de StateFlow (para estados persistentes) y SharedFlow (para eventos efímeros) garantiza una separación de conceptos limpia y predecible. Le estás dando a las vistas de Android y iOS un canal de comunicación asíncrono, robusto y optimizado para los ciclos de vida de cada sistema operativo.

Con este tema cerramos con broche de oro la Unidad 0 de introducción avanzada a Kotlin. Tienes todas las bases del lenguaje dominadas: nulidad, tipos sellados, asincronía y reactividad. Ahora estamos listos para adentrarnos en el desarrollo multiplataforma real y crear nuestro primer monorepo. En el próximo artículo, Unidad 1 — Tema 1: Por qué Kotlin Multiplatform no es otro Flutter/React Native y por qué deberías usarlo, abriremos el debate arquitectónico sobre por qué KMP lidera la nueva era del desarrollo móvil híbrido.