Compose Multiplatform: la misma interfaz en iOS y escritorio

Compose Multiplatform es la parte del ecosistema que despierta más entusiasmo y más desconfianza, y ambas reacciones tienen fundamento porque nacen del mismo hecho técnico. A diferencia de otras soluciones multiplataforma que traducen tus componentes a componentes nativos del sistema, Compose no traduce nada: se lleva consigo su propio motor de dibujo, reserva un lienzo en la pantalla y pinta cada píxel de la interfaz por su cuenta. La consecuencia inmediata es que lo que ves en Android es exactamente lo que ves en iOS, hasta el radio del último borde, sin las divergencias sutiles que atormentan a quien traduce. La consecuencia mediata, y la que hay que entender antes de comprometerse, es que todo aquello que el sistema operativo hacía por ti —seleccionar texto, leerlo en voz alta, reaccionar al gesto de retroceso, mostrar el teclado en el sitio correcto— deja de venir gratis y pasa a ser algo que alguien tiene que reimplementar dentro del lienzo.

Un lienzo propio, no una traducción

En Android, Compose ya dibujaba sobre un lienzo dentro de una vista anfitriona; llevarlo a otras plataformas consistió en sustituir esa vista anfitriona y en apoyar el dibujo sobre un motor gráfico portable. En iOS el resultado es un controlador de vista que aloja una superficie, y dentro de ella el árbol de composición completo. En escritorio es una ventana del sistema con la misma superficie dentro. El árbol de composición, la recomposición, los modificadores, el sistema de medición y colocación, el estado y las animaciones son idénticos en todos los destinos porque son código Kotlin común que no consulta a nadie.

flowchart TD
A[Codigo de UI en commonMain] --> B[Runtime de Compose]
B --> C[Motor de dibujo portable]
C --> D[Superficie en Android]
C --> E[Superficie dentro de un UIViewController]
C --> F[Ventana de escritorio]
E -.->|hay que reconstruirlo dentro| G[Texto, accesibilidad, gestos del sistema]
D -.->|lo aporta el sistema| G

Lo que viaja intacto es más de lo que se supone: el runtime, la biblioteca de interfaz, Material 3, las animaciones, los gestos de pointerInput, la navegación en su versión multiplataforma y las herramientas de previsualización. Lo que no viaja es todo lo que estaba anclado a Android: los recursos a través de la clase generada, el ciclo de vida de las actividades, los permisos, las vistas incrustadas mediante interoperabilidad, las bibliotecas de terceros que solo publican artefactos para Android, y una parte del catálogo de componentes adaptativos que asume convenciones de la plataforma. La sustitución de recursos por el sistema multiplataforma es mecánica y aburrida, pero afecta a cada cadena y cada imagen del proyecto y no conviene descubrirla el último día.

// commonMain: identico a lo que ya escribes en Android
@Composable
fun PantallaSuscripcion(estado: EstadoVisible, onRenovar: () -> Unit) {
    Column(Modifier.fillMaxSize().padding(24.dp)) {
        Text(text = estado.titulo, style = MaterialTheme.typography.headlineSmall)
        Spacer(Modifier.height(12.dp))
        Button(onClick = onRenovar) { Text("Renovar") }
    }
}

// iosMain: el punto de entrada que iOS entiende
fun MainViewController(): UIViewController = ComposeUIViewController {
    AppTheme { PantallaSuscripcion(estado, onRenovar = { /* ... */ }) }
}

Las costuras que hay que conocer antes de decidir

Ninguna de las costuras conocidas es un defecto de implementación pendiente de un parche: todas se derivan de dibujar en lugar de traducir, y por tanto se mitigan pero no desaparecen.

El texto es la primera. Seleccionar, copiar, arrastrar el cursor con la lupa, invocar el menú contextual del sistema y respetar el ajuste de tamaño de fuente del usuario son comportamientos que en iOS pertenecen al componente nativo de texto, y dentro del lienzo hay que reproducirlos. La reproducción ha mejorado de forma notable, pero un usuario de iOS detecta la diferencia en el gesto largo sobre un campo de entrada antes de saber decir por qué.

La accesibilidad es la segunda y la más seria. El árbol de semántica de Compose se puentea hacia el árbol de accesibilidad del sistema, de manera que el lector de pantalla recibe algo con lo que trabajar, pero la correspondencia no es total y el orden de recorrido, las acciones personalizadas y las rotaciones del rotor requieren atención explícita. Una aplicación con obligaciones legales de accesibilidad debe auditar esto en el dispositivo antes de comprometerse, no después.

El tamaño del binario y el tiempo de arranque completan la lista. Incorporar un motor de dibujo y el runtime de Kotlin/Native añade varios megabytes al paquete y un coste de inicialización de la primera composición que en dispositivos antiguos es perceptible. Para una aplicación grande es ruido; para una aplicación pequeña cuyo argumento es la ligereza puede ser un veto.

Queda una costura de naturaleza distinta que no aparece en las listas técnicas y que sin embargo decide muchos proyectos: el desajuste de expectativas dentro del propio equipo. Una pantalla compartida es, por definición, una pantalla que ningún diseñador puede pedir que se comporte según las convenciones de una sola plataforma sin romper la compartición. Cuando el equipo de diseño no ha participado en la decisión, cada revisión de producto se convierte en una negociación sobre si tal detalle se implementa dos veces o se renuncia a él, y esas negociaciones consumen más tiempo que el código que ahorraron.

Recursos, temas y el trabajo diario

Fuera de las costuras conceptuales, la adopción se juega en asuntos prosaicos que ocupan las primeras semanas. El más extenso es el de los recursos: la clase generada de Android desaparece y en su lugar hay un sistema multiplataforma que genera accesores tipados a partir de una carpeta común, con soporte para cadenas, plurales, imágenes y fuentes, y con cualificadores por idioma y por densidad.

// commonMain: los recursos se resuelven en tiempo de composicion
@Composable
fun Cabecera() {
    Row(verticalAlignment = Alignment.CenterVertically) {
        Image(painterResource(Res.drawable.logo), contentDescription = null)
        Spacer(Modifier.width(8.dp))
        Text(stringResource(Res.string.titulo_suscripcion))
    }
}

La conversión es mecánica pero total: afecta a cada cadena traducida, a cada icono y a cada dimensión del proyecto, y no admite una migración parcial elegante porque conviven mal los dos sistemas. Por eso es el trabajo que conviene planificar con nombre propio en el calendario en lugar de dejarlo como detalle de implementación.

El tema es la segunda pieza cotidiana. Material 3 viaja a todos los destinos, incluidos el esquema de color, la tipografía y las formas, pero el color dinámico extraído del fondo de pantalla es una capacidad de Android que en iOS no tiene equivalente ni sentido. La solución habitual consiste en declarar un tema propio en el común, con sus valores explícitos, y permitir que Android lo sobrescriba con el color dinámico cuando el usuario lo tenga activado.

Madurez en 2026 y la estrategia híbrida

El estado razonable de las cosas a mediados de 2026 es que el destino de escritorio y el de Android son plenamente productivos, que iOS es estable y se usa en producción por empresas serias, y que la web sobre WebAssembly es la frontera activa donde todavía conviene medir antes de prometer. La pregunta útil ya no es si funciona, sino cuánta interfaz merece la pena unificar en un producto concreto.

Merece la pena separar dos afirmaciones que suelen ir juntas y que tienen valores de verdad distintos. Que la tecnología esté madura significa que hace lo que dice y que sus fallos son conocidos y documentados; no significa que la distancia con una interfaz nativa haya desaparecido, porque esa distancia no es un defecto que se corrija sino una consecuencia del método. Un equipo que adopta interfaz compartida esperando paridad total con lo nativo va a sentirse engañado por una tecnología que nunca prometió eso; un equipo que la adopta sabiendo que compra uniformidad y velocidad a cambio de una fracción de familiaridad va a estar razonablemente satisfecho durante años.

La respuesta que mejor envejece casi nunca es todo o nada. Compose Multiplatform se incrusta como un controlador de vista más dentro de una aplicación iOS nativa, lo que permite que la navegación, el arranque, los permisos y las pantallas de mayor exigencia sigan siendo nativos mientras las pantallas densas en lógica y pobres en interacción se comparten. Ese patrón reduce el riesgo a una pantalla, permite medir con usuarios reales antes de ampliar y deja abierta la retirada, que es la propiedad que ninguna decisión de arquitectura debería perder.

// iosApp: la pantalla compartida es un controlador mas dentro de la navegacion nativa
struct PantallaCompartida: UIViewControllerRepresentable {
    func makeUIViewController(context: Context) -> UIViewController {
        MainViewControllerKt.MainViewController()
    }
    func updateUIViewController(_ vc: UIViewController, context: Context) { }
}

El criterio para elegir qué pantalla se comparte primero no debería ser la más fácil, sino la que mejor información produzca. Una pantalla de ajustes es fácil y no enseña nada; un listado con desplazamiento, entrada de texto y estados de carga enseña casi todo lo que hay que saber sobre rendimiento, teclado, accesibilidad y sensación al tacto, y lo enseña en dos semanas en lugar de en dos trimestres.

Las pantallas que casi siempre resultan buenas candidatas son las que están densamente pobladas de reglas y pobremente pobladas de gestos: formularios de alta con validación compleja, resúmenes de estado, historiales, flujos de configuración de producto. Las que casi nunca lo son incluyen la pantalla de inicio, cualquier cosa con cámara o mapa incrustados, los reproductores multimedia con controles del sistema y todo lo que dependa de widgets, atajos o integraciones fuera de la aplicación.