Android ya es Compose-first: qué deben hacer los equipos

En Google I/O 2026 esta semana, Google tomó la decisión que los desarrolladores de Android han estado evitando durante años. Jetpack Compose es ahora la forma oficial y predeterminada de crear interfaces de usuario en Android. El kit de herramientas View, el mundo de TextView, ListView, ConstraintLayout y Fragment sobre el que aún se ejecutan la mayoría de las aplicaciones en producción, está en modo de mantenimiento. Recibe correcciones críticas y nada más.

Google fue cuidadoso con las palabras. Las Views no están obsoletas y no hay una fecha de eliminación. Pero «modo de mantenimiento» tiene un significado preciso aquí. Sin nuevas características, sin nuevas API, y cualquier nueva herramienta de interfaz de usuario de Android Studio está congelada, incluidos el Editor de diseño y el Editor de navegación. Las nuevas bibliotecas de Jetpack, la documentación, los codelabs y las muestras serán Compose-first. La guía oficial es directa: construya la nueva interfaz de usuario en Compose y convierta las pantallas existentes a medida que las modifique.

Hemos lanzado aplicaciones nativas de Android en sectores de salud, IoT y comercio electrónico durante años, y la mayoría de ellas comenzaron como proyectos basados en Views. Por lo tanto, esto es una decisión real para muchos equipos, no solo un titular. Así es como lo interpretamos.

El riesgo práctico no es que su aplicación falle. No lo hará. El riesgo es más lento que eso. Su base de código se va desplazando silenciosamente hacia una isla sin soporte. Cada nueva capacidad de Android, cada nuevo componente de Material, cada mejora en las herramientas asume ahora Compose. Un equipo que siga usando Views en 2027 no está en peligro, simplemente está pagando un coste cada vez mayor en soluciones alternativas y características faltantes.

El instinto de «reescribir toda la aplicación» es el equivocado. Hemos visto cómo las reescrituras masivas de interfaz de usuario se estancan durante meses y generan regresiones, y Compose está diseñado para el enfoque contrario. ComposeView y AndroidView permiten que Compose y Views se ejecuten en la misma pantalla, incluso en el mismo diseño. Puede convertir una pantalla, luego un componente, y los usuarios nunca verán la unión. Compose 1.11, también presentado en el I/O, mejoró el rendimiento específicamente para estas pantallas híbridas.

También hay un aspecto de contratación que es fácil pasar por alto. Compose es lo que los nuevos desarrolladores de Android aprenden ahora. Los candidatos lo esperan y la documentación actual lo asume. Una base de código basada principalmente en Views es cada vez más difícil de contratar, y ese coste permanece invisible hasta que lleva tres meses buscando.

Google también presentó una vista previa de un Asistente de Migración de Android Studio que usa un agente de IA para portar pantallas, y AI Studio ahora puede generar aplicaciones en Compose a partir de un prompt. Esto será de ayuda. Pero de nuestro propio trabajo integrando agentes de IA en pipelines de entrega reales, la lección se repite constantemente: un agente que convierte una pantalla solo es útil si un desarrollador que conoce Compose revisa el resultado. Trate una migración generada como un borrador, no como un resultado. Los equipos que salen perjudicados son aquellos que permiten que el volumen de conversiones supere su capacidad de revisión.

Si mantiene una aplicación Android basada en Views, haga una cosa concreta este trimestre. Elija su próxima pantalla genuinamente nueva y constrúyala en Compose, de principio a fin, con la interoperabilidad configurada correctamente. No una prueba de concepto, sino una pantalla que realmente lance. Ese único ejercicio le dirá más que cualquier documento de planificación: cómo su equipo maneja el estado de Compose, dónde su sistema de diseño necesita equivalentes en Compose, cómo se adapta su configuración de compilación y pruebas. Luego establezca una regla simple. Cada pantalla que modifique de forma sustancial se convierte. Constante y aburrido, pero se acumula.

Una cosa más para los equipos que trabajan tanto con iOS como con Android. Compose-first en Android está en línea con donde SwiftUI ya se encuentra en iOS. Ambas plataformas esperan ahora una capa de interfaz de usuario declarativa y dirigida por estado. Si está planificando trabajo nativo en iOS y Android, este es un buen momento para alinear su arquitectura de modo que las dos plataformas razonen sobre la interfaz de usuario de la misma manera. Hace que las bases de código sean más fáciles de dotar de personal y más fáciles de revisar, algo que hemos visto rendir frutos en nuestros proyectos móviles anteriores.

Esto no es una emergencia. Es una dirección. La plataforma de interfaz de usuario de Android tiene ahora un valor predeterminado claro, y el coste de ignorarlo no es un fallo. Es una acumulación lenta de fricción.

Si una pila de pantallas Android basadas en Views sin un plan de migración claro le resulta familiar, hablemos.