1. Un salto tecnológico inevitable
Durante más de 12 años, la forma de crear interfaces de usuario en Android ha dependido de los
pesados archivos XML vinculados a enormes clases Activity mediante
findViewById(). Pero, desde hace ya un tiempo, Google impulsa agresivamente su
alternativa al estilo React o Flutter: Jetpack Compose, una librería nativa
declarativa escrita 100% en Kotlin.
2. ¿Qué significa "Declarativo" frente a "Imperativo"?
En el antiguo sistema XML (paradigma imperativo), el programador le decía al sistema *cómo* mutar
la pantalla paso a paso. Se creaba un botón escondido, y luego escribíamos
button.setVisibility(VISIBLE) y luego button.setText("Cargando").
Con Compose (paradigma declarativo), el programador se concentra únicamente en *qué* aspecto debe tener la pantalla hoy en relación a un "Estado". Si tu clase ViewModel tiene una variable booleana "isLoading", la vista se reescribirá instantáneamente cuando esa variable cambie para representar ese nuevo estado. Esto elimina millones de bugs de estado inconsistente que frustraban la existencia de todo Android dev.
3. Ventajas innegables de Compose
- Menos código (y más en Kotlin): No tienes que alternar entre un archivo de layout (XML) que define las estructuras y uno de Kotlin que provee la lógica. Todo ocurre fluidamente usando el inmenso poder de las funciones de alto orden de Kotlin.
- Manejo del Estado sin fricción: Usar
StateFlowoLiveDatajunto con Compose produce interfaces dinámicas que reaccionan mágicamente sin los tediosos callbacks o escuchadores (listeners) desactualizados. - Animaciones modernas al fin viables: Todo el que ha tratado de animar de
forma fluida un cambio brusco de vista en XML sabe el martirio que es. Compose ofrece APIs
de transición como
animateContentSize()oAnimatedVisibilityque parecen salidas de magia negra, permitiendo modernizar tu App a los estándares competitivos en 2 líneas de código. - Reusabilidad real: Un componente de Compose no es más que una función de
Kotlin anotada con
@Composable. Eso permite una flexibilidad para crear un sistema de diseño inalcanzable para los anticuados archivos *styles.xml*.
4. ¿Murió definitivamente el XML?
En 2026, iniciar un nuevo proyecto Android con XML es visto como una decisión de "deuda técnica". Las directrices oficiales (Modern Android Development, MAD) instan claramente al uso de Jetpack Compose de la misma forma que en su momento fue forzosa la transición de Java a Kotlin.
Sin embargo, hay dos lugares donde el XML todavía vive en las catacumbas de Android:
- Código Legacy en grandes corporaciones: Miles de apps bancarias y
corporativas tienen infraestructuras monolíticas que resultan trágicamente caras y riesgosas
de refactorizar de golpe a Compose, por más puentes (
ComposeViewyAndroidView) que Google haya creado para la interoperabilidad. - Pequeñas personalizaciones de la librería del SO: Parches de compatibilidad minúsculos en ciertos recursos globales del res/ o configuración vectorial muy específica, aunque cada día es menos necesario.
5. Decisión para el equipo Indie
No lo dudes. Si vas a lanzar tu app como Androfus o el próximo competidor de AegisSentinel, construirlo enteramente en Compose te dotará de una agilidad bestial. El problema inicial suele ser la profunda curva de aprendizaje, sobre todo en comprender la gestión de los Efectos Secundarios (SideEffects como LaunchedEffect). Sin embargo, una vez asimilado el modelo mental, programar la UI de Android pasará de ser un castigo con errores en tiempo de compilación R2 a una actividad enormemente creativa y funcional.