Las tres tecnologías permiten reducir trabajo duplicado entre Android e iOS, pero lo hacen con filosofías diferentes. Flutter propone controlar casi toda la interfaz desde su propio motor. React Native combina JavaScript o TypeScript con componentes nativos. Kotlin Multiplatform comparte código Kotlin sin obligarte a renunciar a una interfaz nativa por plataforma.

Tres enfoques para un mismo problema

Flutter permite construir aplicaciones multiplataforma desde una única base de código en Dart. Su interfaz se compone de widgets y se renderiza mediante su propio framework gráfico, lo que favorece una apariencia consistente entre plataformas. (Documentación de Flutter)

React Native parte del ecosistema React. La interfaz se declara con JavaScript o TypeScript, pero se apoya en vistas nativas para representar los componentes. Su arquitectura moderna incorpora Fabric, TurboModules y Codegen para mejorar la comunicación entre la capa JavaScript y el código nativo. (reactnative.dev)

Kotlin Multiplatform, en cambio, no es exclusivamente un framework de interfaz. Su propuesta principal es compartir lógica de negocio, modelos, red, persistencia y casos de uso en Kotlin, manteniendo interfaces nativas con Jetpack Compose en Android y SwiftUI o UIKit en iOS cuando sea necesario. Compose Multiplatform permite compartir también la UI, pero es una decisión opcional. (Kotlin)

Flutter: una experiencia visual uniforme

Flutter destaca cuando el producto necesita una interfaz muy personalizada y homogénea en Android e iOS. Al no depender de que cada plataforma represente cada componente de la misma forma, resulta más sencillo mantener animaciones, layouts y estilos coherentes.

También es una opción atractiva para equipos pequeños que quieren lanzar un producto multiplataforma rápido, especialmente si no tienen una base Android o iOS existente que deban conservar. Flutter soporta además objetivos como web y escritorio desde el mismo ecosistema, aunque cada plataforma debe evaluarse según las necesidades reales del producto. (Documentación de Flutter)

Su principal coste aparece cuando necesitas integrarte profundamente con APIs específicas del sistema o con SDKs nativos poco habituales. Hay paquetes para muchas integraciones, pero cualquier carencia puede obligar a escribir código en Kotlin, Java, Swift u Objective-C mediante canales de plataforma.

React Native: aprovechar el talento web

React Native tiene una ventaja clara: acerca el desarrollo móvil a equipos que ya dominan React, TypeScript y las prácticas del frontend web. Para una organización con una base sólida de desarrolladores JavaScript, la curva de aprendizaje puede ser menor que adoptar Dart o Kotlin Multiplatform.

La propuesta no significa que Android e iOS desaparezcan. Las aplicaciones reales siguen necesitando configuración nativa, compilación con Gradle y Xcode, permisos, notificaciones, analítica y, en algunos casos, módulos propios. La nueva arquitectura reduce limitaciones históricas del puente tradicional, pero también introduce requisitos de compatibilidad que las librerías del ecosistema deben adoptar. (reactnative.dev)

React Native es una buena elección cuando la velocidad de desarrollo depende de reutilizar conocimiento web y el producto no exige un control extremo sobre cada detalle visual o cada API nativa desde el primer día.

Kotlin Multiplatform: compartir sin sustituir lo nativo

Kotlin Multiplatform es especialmente interesante para equipos Android que ya usan Kotlin, arquitectura por capas, coroutines y bibliotecas del ecosistema JetBrains. Permite compartir el núcleo de una aplicación sin obligar a que Android e iOS se comporten como la misma plataforma.

Un caso típico es mantener una UI con Jetpack Compose en Android y SwiftUI en iOS, mientras se comparten modelos, reglas de negocio, autenticación, clientes HTTP y repositorios. Así, cada plataforma puede respetar sus patrones y convenciones de interacción sin duplicar la lógica crítica.

// commonMain
data class UserProfile(
    val id: String,
    val name: String,
    val isPremium: Boolean
)

class ProfileUseCase(
    private val repository: ProfileRepository
) {
    suspend fun loadProfile(userId: String): UserProfile {
        return repository.getProfile(userId)
    }

    fun canAccessDownloads(profile: UserProfile): Boolean {
        return profile.isPremium
    }
}

Este enfoque es útil cuando una app Android madura necesita llegar a iOS de forma progresiva. No es necesario reescribir todo: puedes empezar compartiendo una capa concreta y ampliar la adopción cuando el equipo y la arquitectura estén preparados. La documentación oficial recomienda separar la lógica compartida de la UI compartida cuando alguna plataforma mantendrá una interfaz nativa. (Kotlin)

Compose Multiplatform amplía la reutilización hacia la interfaz. Actualmente es estable para Android, iOS y escritorio, mientras que el objetivo web continúa en beta. (Kotlin)

Rendimiento y experiencia nativa

No conviene resumir el rendimiento en una tabla de “rápido” o “lento”. En las tres opciones, una aplicación puede ofrecer una experiencia excelente o presentar problemas si la arquitectura, las listas, las imágenes y el trabajo en segundo plano se diseñan mal.

Flutter controla su pipeline de renderizado y su motor Impeller busca evitar bloqueos asociados a la compilación de shaders durante animaciones e interacciones. (Documentación de Flutter) React Native representa componentes nativos y ha evolucionado su arquitectura para mejorar la coordinación entre JavaScript y las capas de plataforma. Kotlin Multiplatform compila código para cada destino y permite conservar UI nativa o compartirla con Compose Multiplatform. (reactnative.dev)

La experiencia más “nativa” no depende solo de la tecnología. Depende de respetar patrones de navegación, accesibilidad, tipografía, gestos y expectativas propias de Android e iOS.

Una decisión práctica

La siguiente guía puede servir como punto de partida:

Conclusión

Flutter, React Native y Kotlin Multiplatform son soluciones válidas, pero no intercambiables. Flutter prioriza consistencia visual y control del rendering. React Native aprovecha el ecosistema web y React. Kotlin Multiplatform prioriza compartir código estratégico sin perder la libertad de construir experiencias nativas.

Para un equipo Android, Kotlin Multiplatform suele ser la opción más alineada cuando ya existe una app, una arquitectura Kotlin consolidada o una necesidad real de preservar la identidad de cada plataforma. Para un producto nuevo, sin legado y con una interfaz altamente personalizada, Flutter puede acelerar la salida al mercado. Y cuando la empresa vive en React, React Native mantiene una propuesta difícil de ignorar.

La elección correcta no es la que comparte más código: es la que reduce complejidad sin comprometer el producto.

La biblioteca está diseñada para Kotlin y Java, incorpora dependencias específicas para Android y permite ejecutar modelos en el dispositivo mediante Gemini Nano y las APIs de ML Kit GenAI. También puede trabajar con modelos cloud o combinar ambos enfoques en una arquitectura híbrida. (Android Developers)

Qué es exactamente un agente con ADK

Un agente es una unidad de software que recibe una intención del usuario, interpreta el contexto, decide qué pasos necesita ejecutar y genera una respuesta. Para hacerlo, puede apoyarse en un modelo de lenguaje, herramientas de tu aplicación y otros agentes especializados.

Por ejemplo, una app de viajes podría tener:

• Un agente principal que entiende la petición del usuario.
• Un agente local que resume reservas ya almacenadas en el dispositivo.
• Un agente cloud que propone un itinerario.
• Herramientas para consultar vuelos, guardar favoritos o crear recordatorios.

ADK aporta la estructura para organizar esa colaboración. En lugar de repartir lógica de prompts, estados y llamadas a servicios por distintos ViewModel, puedes concentrar la responsabilidad en una capa de agentes.

Cuándo conviene integrarlo en una app Android

ADK resulta útil cuando la IA necesita razonar sobre una petición, consultar información contextual o ejecutar varias acciones coordinadas.

Algunos casos claros son:

No es la mejor opción para cada funcionalidad de IA. Si solo necesitas resumir un texto, corregir una frase o clasificar una imagen, una API específica de ML Kit puede ser más simple y predecible. ADK merece la pena cuando hay decisiones, contexto, herramientas o varios pasos.

Ejecución local, cloud o híbrida

La decisión más importante no es el prompt, sino dónde se ejecuta la inferencia.

Modelo en el dispositivo

Con Gemini Nano a través de ML Kit GenAI, la inferencia puede realizarse sin conexión y sin enviar el contenido a la nube. Esto reduce la latencia de red, mejora la privacidad y evita costes por petición, aunque el rendimiento depende del hardware y de la disponibilidad del modelo en cada dispositivo. (Android Developers)

Encaja especialmente bien en funcionalidades como:

• Resumen de notas privadas.
• Reescritura de mensajes.
• Asistentes que trabajan con contenido local.
• Funciones disponibles sin conexión.

Modelo en la nube

Un modelo cloud suele ofrecer mayor capacidad para tareas complejas, acceso a información remota y respuestas más ricas. A cambio, añade latencia, coste, conectividad y requisitos de seguridad.

Arquitectura híbrida

El enfoque híbrido combina ambas opciones. Un agente principal puede usar un modelo cloud para coordinar el flujo, mientras subagentes locales procesan información sensible, como notas, historial o documentos descargados.

Esta arquitectura permite equilibrar privacidad y capacidad. Por ejemplo, una app de salud podría resumir localmente síntomas registrados por el usuario y enviar al backend solo una representación mínima y consentida para obtener contenido educativo.

Configura ADK en el proyecto

Actualmente, ADK para Android requiere minSdk 24 o superior, compileSdk 34 o superior, Java 17 y KSP para procesar anotaciones como @Tool. La dependencia Android reemplaza a la variante JVM: no debes añadir ambas. (Android Developers)

plugins {
    id("com.android.application")
    kotlin("android")
    id("com.google.devtools.ksp") version "2.1.20-2.0.1"
}

android {
    compileSdk = 34

    defaultConfig {
        minSdk = 24
        targetSdk = 34
    }
}

dependencies {
    implementation("com.google.adk:google-adk-kotlin-core-android:0.1.0")
    ksp("com.google.adk:google-adk-kotlin-processor:0.1.0")
}

kotlin {
    jvmToolchain(17)
}

Revisa siempre la documentación antes de copiar versiones: ADK para Android sigue evolucionando y sus artefactos pueden cambiar.

Crea un agente local sencillo

El siguiente ejemplo crea un agente que trabaja con un modelo local ya inicializado mediante ML Kit. En una app real, conviene exponerlo desde una capa de dominio o un repositorio, no crearlo directamente en un Composable.

import com.google.adk.kt.agents.Instruction
import com.google.adk.kt.agents.LlmAgent
import com.google.adk.kt.models.mlkit.GenaiPrompt
import com.google.adk.kt.runners.InMemoryRunner
import com.google.adk.kt.sessions.InMemorySessionService
import com.google.adk.kt.types.Content
import com.google.adk.kt.types.Part
import com.google.adk.kt.types.Role
import com.google.mlkit.genai.prompt.GenerativeModel
import kotlinx.coroutines.flow.Flow

class NotesAssistant(
    generativeModel: GenerativeModel
) {
    private val model = GenaiPrompt.create(
        generativeModel = generativeModel,
        name = "gemini-nano"
    )

    private val agent = LlmAgent(
        name = "notes_assistant",
        description = "Resume y organiza notas del usuario.",
        model = model,
        instruction = Instruction(
            "Responde en español. Resume el contenido con claridad y " +
                "no inventes información que no aparezca en la nota."
        )
    )

    private val runner = InMemoryRunner(
        agent = agent,
        sessionService = InMemorySessionService()
    )

    fun ask(note: String): Flow<Any> {
        return runner.runAsync(
            userId = "current-user",
            sessionId = "notes-session",
            newMessage = Content(
                role = Role.USER,
                parts = listOf(
                    Part(text = "Resume esta nota:\n$note")
                )
            )
        )
    }
}

El InMemoryRunner ejecuta el agente y expone los eventos de respuesta como un flujo. En Android, recógelo desde un ViewModel con viewModelScope y publica el texto final o los fragmentos parciales en el estado de UI. La documentación oficial muestra este patrón basado en corrutinas y collect. (Android Developers)

Añade herramientas cuando el agente debe actuar

El valor diferencial de ADK aparece cuando el agente puede usar funciones de tu app. Una herramienta puede consultar una base de datos local, recuperar una reserva, crear una tarea o buscar un producto.

Define funciones pequeñas, deterministas y con permisos claros. Evita exponer operaciones destructivas sin confirmación explícita del usuario.

import com.google.adk.kt.annotations.Param
import com.google.adk.kt.annotations.Tool

class TaskTools(
    private val repository: TasksRepository
) {
    @Tool
    suspend fun getPendingTasks(
        @Param("Categoría opcional para filtrar tareas")
        category: String?
    ): List<String> {
        return repository.pendingTasks(category)
            .map { task -> task.title }
    }
}

Después puedes registrar las herramientas generadas en el agente mediante tools = TaskTools(repository).generatedTools(). Mantén estas operaciones dentro de tu capa de datos o dominio: el agente decide cuándo pedir una acción, pero tu aplicación conserva las reglas de negocio, autorización y validación.

Recomendaciones para producción

Empieza con un único agente y una única capacidad útil. Un flujo pequeño es más fácil de probar, medir y proteger que una red de subagentes creada demasiado pronto.

También conviene aplicar estas reglas:

• Conserva las decisiones críticas fuera del modelo.
• Pide confirmación antes de compras, borrados, envíos o cambios de cuenta.
• Registra métricas de latencia, errores, cancelaciones y coste por interacción.
• Diseña estados de carga y recuperación ante falta de red.
• Trata la salida del modelo como contenido no confiable hasta validarla.
• Prueba en dispositivos reales si dependes de inferencia local.

ADK no sustituye la arquitectura Android habitual. Sigue necesitando ViewModel, repositorios, control de permisos, pruebas y una UI clara. Su función es aportar una capa de orquestación para experiencias de IA que ya no caben en una sola llamada a un modelo.

Qué son realmente los Style

Un Style define propiedades visuales como fondo, padding, bordes, forma, sombras, tamaño, transformaciones o atributos tipográficos. Puedes pasarlo a un componente que exponga un parámetro style o aplicarlo sobre layouts mediante Modifier.styleable. (Android Developers)

La diferencia clave es que un Style funciona como una capa de propiedades sobrescribibles. Si defines dos veces un fondo, se aplicará el último. Con los modifiers ocurre lo contrario: normalmente se encadenan de forma aditiva. Añadir dos bordes con Modifier.border() puede dibujar dos bordes; aplicar dos fondos en un Style reemplaza el anterior. (Android Developers)

Esto cambia cómo modelamos un design system. En lugar de construir una larga cadena de Modifier en cada pantalla, puedes definir un estilo base y reemplazar solamente las propiedades que cambian.

Style no reemplaza a Modifier

La forma correcta de entender la API es esta: Style es un tipo especializado de Modifier orientado a configuración visual. Todo lo que logra un Style puede conseguirse con modifiers, pero Style no cubre todas las capacidades de Modifier. (Android Developers)

Un componente puede usar ambos sin problema: Modifier para hacerlo pulsable o colocarlo en pantalla, y Style para decidir cómo se ve.

Un ejemplo con estados y animación

El siguiente ejemplo aplica un Style a un Box. El Modifier.clickable conserva la responsabilidad de la interacción, mientras que Style define fondo, padding, forma y respuesta visual al estado pressed.

@Composable
fun SaveSurface(
    onSave: () -> Unit,
    modifier: Modifier = Modifier
) {
    val interactionSource = remember { MutableInteractionSource() }
    val styleState = remember(interactionSource) {
        MutableStyleState(interactionSource)
    }

    val saveStyle = Style {
        externalPadding(horizontal = 16.dp, vertical = 8.dp)
        contentPadding(20.dp)
        shape(RoundedCornerShape(20.dp))
        background(Color(0xFF6750A4))

        pressed {
            animate {
                background(Color(0xFF4F378B))
            }

            animate(
                spring(
                    dampingRatio = Spring.DampingRatioMediumBouncy
                )
            ) {
                scale(0.98f)
            }
        }
    }

    Box(
        modifier = modifier
            .clickable(
                interactionSource = interactionSource,
                indication = null,
                onClick = onSave
            )
            .styleable(styleState, saveStyle)
    ) {
        Text("Guardar cambios")
    }
}

Con modifiers tradicionales, este comportamiento suele implicar observar el estado de interacción, calcular valores con animateColorAsState o APIs similares y aplicar las animaciones manualmente. Los Style permiten declarar esas variaciones dentro del propio estilo mediante bloques como pressed, hovered o focused, además de incluir animate para interpolar propiedades visuales. (Android Developers)

Por qué supone una mejora

Estados visuales más declarativos

Un botón puede tener estilos distintos cuando está deshabilitado, seleccionado, enfocado o pulsado. Con StyleState, estas reglas viven en el mismo lugar que el resto de la apariencia, en lugar de dispersarse entre condiciones, animaciones y cadenas de modifiers. La API también admite estados personalizados, útiles para componentes de reproducción, carga, error o selección. (Android Developers)

Mejor encaje con el theming

Los styles pueden definirse como valores reutilizables y combinarse con then. Esto permite partir de una apariencia base y crear variantes sin duplicar toda la configuración. Además, pueden leer valores de CompositionLocal, una pieza importante para conectarlos con tokens de diseño globales. (Android Developers)

Animaciones visuales con menos recomposición

Según la documentación de Compose, los cambios de Style se resuelven en las fases de layout y dibujo, evitando la fase de composición en muchas actualizaciones visuales. Esto resulta especialmente interesante para animar color, escala, bordes o padding durante interacciones frecuentes. (Android Developers)

Cuándo usarlo en un proyecto real

Style encaja especialmente bien en componentes propios de un design system: tarjetas, botones internos, chips, superficies interactivas o controles que necesiten muchas variantes visuales. También es una buena opción cuando quieres reemplazar valores por defecto sin que las propiedades se acumulen de forma inesperada.

No conviene usarlo por inercia para cada Box o Text. Resolver un estilo completo puede tener más coste que aplicar un único modifier, y los modifiers siguen siendo imprescindibles para comportamiento y accesibilidad. (Android Developers)

La mejora no consiste en dejar de usar Modifier, sino en evitar que tenga que resolver todos los problemas de estilo. Usa Style para expresar identidad visual, variantes, estados y transiciones; usa Modifier para definir comportamiento y contexto. Esa separación hace que los componentes sean más coherentes, las APIs más pequeñas y el design system más fácil de mantener.

Android permite que aplicaciones móviles y optimizadas para pantallas grandes funcionen en XR, pero una aplicación realmente diferenciada añade capacidades específicas como paneles espaciales, modelos 3D, audio espacial o entornos inmersivos. (Android Developers)

Diseñar para un espacio, no para una pantalla

Una aplicación XR puede funcionar en dos contextos principales. En Home Space, el usuario mantiene varias aplicaciones abiertas y trabaja con paneles acotados. En Full Space, la aplicación toma el protagonismo y puede acceder a experiencias inmersivas, contenido 3D y una interfaz espacial más amplia. (Android Developers)

Esta diferencia debe guiar la arquitectura de producto:

• Usa Home Space para productividad, mensajería, listas, reproducción de contenido o consultas rápidas.
• Reserva Full Space para tareas que realmente se beneficien de la inmersión: formación práctica, visualización de datos, recorridos 3D, edición audiovisual o experiencias de bienestar.
• Permite que el usuario cambie de contexto sin perder su progreso.

Una buena aplicación XR no fuerza la inmersión. La propone cuando aporta una ventaja clara.

Principios para crear buenas aplicaciones Android XR

Prioriza la utilidad frente al efecto visual

Un panel flotando en el espacio no mejora automáticamente una aplicación. Antes de añadir profundidad, pregúntate qué problema resuelve.

Por ejemplo, una aplicación de cursos puede mostrar el vídeo principal delante del usuario, una guía de ejercicios a un lado y una lista de recursos al otro. En cambio, una pantalla de inicio de sesión, una configuración de cuenta o un formulario de pago suelen funcionar mejor como interfaces convencionales.

Los paneles espaciales son contenedores para interfaz, contenido interactivo y experiencias inmersivas. Jetpack Compose para XR permite construirlos con conceptos familiares de Compose, como filas, columnas y composables reutilizables. (Android Developers)

Diseña para manos, mirada y otros métodos de entrada

En XR, el usuario puede interactuar con mirada, gestos, manos, controladores, teclado o trackpad. No asumas que tendrá un mando ni que podrá realizar movimientos muy precisos durante varios minutos.

Android recomienda controles táctiles de al menos 48dp, con 56dp como tamaño recomendado para mejorar la comodidad y la precisión. También es importante evitar movimientos bruscos de cámara y mantener referencias visuales estables para reducir el riesgo de mareo. (Android Developers)

Esto se traduce en decisiones concretas:

• Botones grandes y separados.
• Pocos controles visibles al mismo tiempo.
• Texto legible desde diferentes distancias.
• Animaciones suaves y breves.
• Acciones importantes disponibles sin gestos complejos.

Mantén la navegación cerca del contenido

En una interfaz espacial, la navegación no debería obligar al usuario a recorrer visualmente toda la escena. Los Orbiterspermiten asociar controles contextuales a un panel, por ejemplo para pausar un vídeo, cambiar de lección o abrir acciones relacionadas con el contenido actual. (Android Developers)

Esto ayuda a que la interfaz siga siendo comprensible sin llenar el espacio de menús flotantes.

El smartphone como compañero, no como duplicado

La mejor relación entre Android XR y el móvil es complementaria. El smartphone sigue siendo excelente para tareas privadas, rápidas y de alta densidad de información. XR destaca cuando la información necesita espacio, contexto o atención sostenida.

Para gafas de audio o de pantalla, Android XR contempla un modelo en el que la aplicación se ejecuta en un dispositivo anfitrión, como un teléfono Android, y proyecta la experiencia hacia las gafas mediante Jetpack Projected. (Android Developers)

Esto permite plantear un flujo continuo: el usuario prepara una sesión en el móvil, consume o explora contenido en XR y vuelve al teléfono para compartir resultados, revisar detalles o continuar una tarea fuera del visor.

Un ejemplo de adaptación progresiva con Compose

No es necesario reescribir toda la aplicación para probar una interfaz espacial. Puedes conservar la misma pantalla principal y mostrarla dentro de un panel espacial cuando el dispositivo lo permita.

@Composable
fun CourseWorkspace() {
    if (LocalSpatialCapabilities.current.isSpatialUiEnabled) {
        Subspace {
            SpatialPanel(
                modifier = SubspaceModifier
                    .transformingMovable()
                    .transformingResizable()
            ) {
                CourseContent()
            }
        }
    } else {
        CourseContent()
    }
}

Este patrón mantiene una única implementación de CourseContent() y añade comportamiento XR solo cuando la interfaz espacial está disponible. Android recomienda comprobar las capacidades espaciales en tiempo de ejecución, ya que pueden variar según el dispositivo y el contexto de uso. (Android Developers)

Arquitectura recomendada para experiencias multidispositivo

La continuidad entre móvil y XR es más importante que la apariencia de los paneles. Para conseguirla:

1. Centraliza el estado de usuario, progreso y contenido en una capa compartida.
2. Mantén la lógica de dominio separada de la interfaz.
3. Diseña pantallas específicas para móvil y XR, aunque compartan casos de uso.
4. Sincroniza el punto exacto donde el usuario dejó una tarea.
5. Permite iniciar una acción en un dispositivo y terminarla en otro.

Kotlin Multiplatform puede ser especialmente útil aquí. Puedes compartir modelos, reglas de negocio, repositorios y casos de uso entre plataformas, mientras cada interfaz adopta los patrones adecuados para su contexto. El móvil puede priorizar velocidad y densidad; XR, espacio, foco y contexto.

Una estrategia realista para empezar

Empieza identificando un único flujo donde XR aporte valor medible. Puede ser una lección práctica, un visor de planos, una experiencia de compra con objetos 3D o una pantalla de trabajo con varios documentos.

Después, optimiza primero tu aplicación para pantallas grandes y entrada externa. Cuando esa base sea sólida, adapta componentes Material 3 y añade uno o dos elementos espaciales, como un SpatialPanel o un Orbiter. Material Design para XR permite que componentes y layouts existentes adopten comportamientos espaciales en dispositivos compatibles. (Android Developers)

Android XR tendrá más impacto en las aplicaciones que entiendan una idea simple: el smartphone sigue siendo el centro personal y portátil; XR puede convertirse en el espacio donde ese contenido gana contexto, escala y presencia.

Lifecycle 2.11.0 introduce una solución nativa para este caso: Scoped ViewModels. Con ella puedes asociar un ViewModel a una parte concreta de la composición, conservarlo ante cambios de configuración y liberarlo automáticamente cuando esa parte abandona el árbol de UI. (Android Developers)

El problema: el alcance no siempre coincide con la UI

La función viewModel() obtiene la instancia desde el ViewModelStoreOwner más cercano disponible en LocalViewModelStoreOwner. En una app Compose con Navigation, ese propietario suele ser el NavBackStackEntry actual; sin Navigation, puede ser la Activity. (Android Developers)

Eso funciona muy bien para una pantalla completa: por ejemplo, DetailViewModel asociado a la ruta de detalle. Sin embargo, hay componentes que tienen vida propia dentro de una pantalla:

• Cada página de un HorizontalPager.
• Un editor temporal que aparece y desaparece.
• Un panel expandible con operaciones asíncronas.
• Una zona de UI dinámica con estado complejo e independiente.

Antes, para darles un ciclo de vida específico, era habitual crear y limpiar ViewModelStore manualmente o aceptar que el estado viviera más tiempo del necesario. La nueva API elimina ese trabajo y hace explícito el alcance desde Compose.

Las tres piezas de Scoped ViewModels

Lifecycle 2.11.0 incorpora tres APIs relacionadas:

• rememberViewModelStoreOwner(): crea un ViewModelStoreOwner asociado al punto donde se invoca el composable.
• rememberViewModelStoreProvider(): conserva un proveedor de stores para crear varios alcances independientes.
• ViewModelStoreProvider: es la pieza de más bajo nivel que gestiona los stores hijos y su relación con el propietario padre. (Android Developers)

La API principal para la mayoría de casos es rememberViewModelStoreOwner(). El ViewModel asociado a ese owner sobrevive a una rotación, pero se limpia cuando el composable que lo contiene deja la composición. (Android Developers)

Añade la dependencia

Incluye el artefacto de Compose para ViewModel. La versión 2.11.0 fue publicada el 17 de junio de 2026. (Android Developers)

dependencies {
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.11.0")
}

Ejemplo: un ViewModel por página en un Pager

Imagina un catálogo donde cada página permite escribir una nota temporal sobre un producto. Cada producto necesita conservar su propia nota mientras su página está en composición, sin compartirla con el resto.

data class ProductPageUiState(
    val note: String = ""
)

class ProductPageViewModel(
    private val productId: String
) : ViewModel() {

    var uiState by mutableStateOf(ProductPageUiState())
        private set

    fun onNoteChanged(note: String) {
        uiState = uiState.copy(note = note)
    }
}

@Composable
fun ProductPager(productIds: List<String>) {
    val pagerState = rememberPagerState(
        pageCount = { productIds.size }
    )

    val storeProvider = rememberViewModelStoreProvider()

    HorizontalPager(state = pagerState) { page ->
        val productId = productIds[page]

        val pageOwner = rememberViewModelStoreOwner(
            provider = storeProvider,
            key = productId
        )

        CompositionLocalProvider(
            LocalViewModelStoreOwner provides pageOwner
        ) {
            val pageViewModel: ProductPageViewModel = viewModel {
                ProductPageViewModel(productId)
            }

            ProductPage(
                note = pageViewModel.uiState.note,
                onNoteChanged = pageViewModel::onNoteChanged
            )
        }
    }
}

rememberViewModelStoreProvider() mantiene el proveedor común, mientras que rememberViewModelStoreOwner() crea un owner distinto por cada clave. En este caso, productId identifica de forma estable la página y evita mezclar el estado entre productos.

Al proporcionar pageOwner mediante CompositionLocalProvider, cualquier llamada a viewModel() dentro de ese bloque utiliza el nuevo alcance. La documentación oficial muestra este patrón para páginas de HorizontalPager y otros escenarios con varios scopes independientes. (Android Developers)

Cuándo merece la pena usarlo

Scoped ViewModels no sustituye a remember ni a rememberSaveable. Para un campo visual sencillo, una animación o una selección efímera, el estado local suele ser más claro y ligero.

Esta API encaja cuando el bloque de UI necesita lógica, operaciones asíncronas, una fuente de estado propia o independencia real frente a otros bloques hermanos. También es una buena opción cuando un componente dinámico es complejo, pero no representa una pantalla completa.

Las recomendaciones de arquitectura de Android siguen priorizando ViewModel a nivel de pantalla, destino o grafo de navegación. Para piezas de UI reutilizables, suele ser preferible un state holder simple; reserva el scope composable para secciones dinámicas con una responsabilidad de estado clara. (Android Developers)

Matices importantes

Que una página deje de estar visible no implica necesariamente que su ViewModel se destruya de inmediato. Se limpia cuando el composable sale de la composición, y componentes como un pager pueden mantener páginas cercanas preparadas durante un tiempo.

Tampoco debes confundir supervivencia ante rotación con restauración tras muerte de proceso. El nuevo owner protege el ViewModel durante cambios de configuración, pero para recuperar datos tras una finalización del proceso iniciada por el sistema necesitas persistir el estado necesario, por ejemplo mediante SavedStateHandle. (Android Developers)

La gran ventaja de Scoped ViewModels es que el ciclo de vida deja de ser un detalle implícito. Puedes modelar la duración de cada estado según la parte de UI que realmente lo necesita, sin forzar toda la lógica a vivir al nivel de la pantalla.

El espacio para un perfil recién titulado existe, pero suele aparecer bajo nombres distintos: desarrollador Android trainee, programador Kotlin, QA mobile, desarrollador backend Java/Kotlin, soporte de aplicaciones o desarrollador multiplataforma. La clave es no limitar la búsqueda a una única etiqueta.

El mercado mobile para perfiles junior

El desarrollo mobile sigue siendo una especialidad relevante, pero en 2025 muchas empresas redujeron la prioridad de nuevas aplicaciones y concentraron inversión en IA, datos e infraestructura. La guía salarial de Manfred para 2026 describe un mercado mobile con menos movimiento en ofertas y una caída de los salarios en los tramos altos, especialmente frente a otras áreas técnicas. (Get Manfred)

Eso no significa que Android o iOS hayan dejado de ser opciones profesionales. Significa que las empresas valoran más a los candidatos que llegan con proyectos terminados, criterio técnico y capacidad para integrarse en productos ya existentes.

Para un recién titulado de DAM, el primer empleo puede estar más cerca de estas rutas:

Un puesto de mantenimiento puede parecer menos atractivo que crear una aplicación desde cero, pero ofrece una experiencia muy útil. Aprendes a trabajar con incidencias reales, versiones antiguas de Android, dependencias, analítica, errores de producción y ciclos de publicación.

Bandas salariales orientativas en España

Las cifras dependen de la ciudad, el tipo de empresa, el nivel de inglés, la modalidad de trabajo y las tecnologías que domines. Aun así, estas bandas ayudan a tener una referencia para negociar y detectar ofertas claramente por debajo del mercado.

Todos los importes de esta tabla son salarios brutos anuales aproximados.

La guía de Manfred sitúa los perfiles mobile con menos de dos años de experiencia entre 20.000 € y 30.000 € brutos anuales. Para perfiles con dos a cinco años, el rango se mueve entre 31.000 € y 40.000 €. (Get Manfred)

Como referencia más específica, Glassdoor estima para un Junior Android Developer en Madrid una horquilla de salario base entre 23.000 € y 30.000 €, con una compensación total habitual de entre 25.000 € y 32.000 €. Debe tomarse como una señal de mercado, no como una cifra garantizada, porque se basa en salarios compartidos por usuarios. (Glassdoor)

También conviene recordar que Hays sitúa el salario de un desarrollador junior generalista en España entre 25.000 € y 35.000 € brutos anuales. Un perfil mobile con portfolio sólido, inglés funcional y conocimientos de arquitectura puede acercarse antes a la parte alta de ese rango. (Hays Spain)

Qué hace subir o bajar el salario

La ciudad sigue influyendo. Madrid y Barcelona suelen concentrar más empresas de producto, fintech, consultoras tecnológicas y equipos internacionales. Eso puede elevar el salario, aunque también aumenta el coste de vida.

El tipo de empresa también importa. Una consultora puede ofrecer una entrada más accesible, formación y proyectos variados, pero con una banda inicial más ajustada. Una empresa de producto puede pedir más nivel técnico desde el inicio, aunque suele valorar mejor el conocimiento profundo de Android, arquitectura, testing y publicación en Google Play.

Las tecnologías complementarias marcan diferencias. Kotlin es la base para Android moderno, pero saber trabajar con Jetpack Compose, Room, Retrofit, WorkManager, Firebase, CI/CD y testing puede convertir un perfil junior generalista en un candidato más específico.

En perfiles senior, React Native y Flutter mantienen salarios más elevados cuando existe escasez de talento especializado, pero esa prima no suele aplicarse al primer empleo. (Get Manfred)

El portfolio sustituye a la experiencia que todavía no tienes

El título de DAM acredita formación. El portfolio demuestra capacidad para aplicar esa formación. No necesitas publicar diez clones de una red social: necesitas uno o dos proyectos terminados, con una README clara y decisiones técnicas justificadas.

Una aplicación de hábitos, gastos personales o reservas puede demostrar mucho más que una interfaz bonita. Incluye carga de datos, estados de error, persistencia local, navegación, tests y una arquitectura sencilla.

data class HabitUiState(
    val isLoading: Boolean = false,
    val habits: List<Habit> = emptyList(),
    val error: String? = null
)

class HabitViewModel(
    private val repository: HabitRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow(HabitUiState())
    val uiState: StateFlow<HabitUiState> = _uiState.asStateFlow()

    fun loadHabits() {
        viewModelScope.launch {
            _uiState.update { it.copy(isLoading = true, error = null) }

            runCatching { repository.getHabits() }
                .onSuccess { habits ->
                    _uiState.update {
                        it.copy(isLoading = false, habits = habits)
                    }
                }
                .onFailure { exception ->
                    _uiState.update {
                        it.copy(
                            isLoading = false,
                            error = exception.message ?: "Error inesperado"
                        )
                    }
                }
        }
    }
}

Este ejemplo refleja elementos habituales en un proyecto Android: ViewModel, corrutinas, StateFlow, estados de interfaz y tratamiento de errores. No necesitas una arquitectura excesivamente compleja; necesitas demostrar que entiendes por qué usas cada pieza.

Una estrategia realista para entrar en mobile

Especialízate en una ruta principal, como Android con Kotlin y Jetpack Compose, pero mantén una segunda competencia cercana. Backend Kotlin, testing, Firebase, Flutter o Kotlin Multiplatform amplían las oportunidades sin alejarte del ecosistema mobile.

Busca vacantes con términos como Android trainee, Kotlin junior, QA mobile, programador Java, desarrollo multiplataforma o mantenimiento de aplicaciones. Muchas empresas no publican el primer puesto bajo la etiqueta exacta que esperas.

Tu valor como junior no depende de tener años de experiencia. Depende de demostrar que puedes aprender rápido, comunicarte bien, revisar tu propio código y aportar en un equipo desde el primer sprint.

Las skills resuelven ese problema. Son paquetes reutilizables de instrucciones, referencias, scripts y recursos que un agente carga cuando una tarea lo requiere. El repositorio android/skills publica skills mantenidas por Android para tareas específicas, como migraciones de AGP, CameraX, edge-to-edge, Navigation 3, R8 o Android CLI. El formato sigue el estándar abierto Agent Skills y gira alrededor de un archivo SKILL.md. (GitHub)

Qué diferencia hay entre una skill y las instrucciones globales

Antes de instalar nada, conviene separar dos conceptos:

Una skill no debería repetir todo el contexto del proyecto. Debe explicar un flujo concreto, cuándo activarlo y cómo comprobar el resultado. Así el agente no carga instrucciones largas en cada conversación y obtiene detalles solo cuando el trabajo lo necesita.

Instalar Android Skills oficiales

Android distribuye sus skills mediante Android CLI. Puedes instalar una skill concreta en el proyecto actual:

android skills add --skill=r8-analyzer --project=.

Para instalar todas las skills disponibles para los agentes detectados:

android skills add --all

También puedes limitar la instalación a uno o varios agentes usando --agent, o elegir una skill concreta con --skill. Si no indicas una skill ni --all, Android CLI instala únicamente la skill android-cli. (GitHub)

Un flujo razonable para un repositorio Android sería este:

cd mi-app-android
android skills add --all --project=.
git status

Después, revisa qué directorios se han creado y decide cuáles deben versionarse. Para un equipo, lo habitual es mantener las skills de proyecto dentro del repositorio para que todos los desarrolladores y agentes trabajen con las mismas reglas.

Usar Android Skills con Claude Code

Claude Code reconoce skills mediante directorios que contienen un archivo SKILL.md. Puedes guardarlas a nivel personal en ~/.claude/skills/ o solo para un repositorio en .claude/skills/. La ubicación del directorio define el comando disponible: por ejemplo, .claude/skills/android-release/SKILL.md crea la skill /android-release. (code.claude.com)

Paso 1: instala las skills en el proyecto

Desde la raíz del repositorio:

android skills add --all --project=.

Comprueba si el instalador ha creado o actualizado directorios para Claude. Después inicia Claude Code desde la raíz:

claude

Paso 2: consulta las skills detectadas

En Claude Code, abre el selector de skills o escribe / para ver las disponibles. Una skill puede activarse de dos formas:

• De manera explícita, escribiendo su comando.
• De forma automática, cuando Claude interpreta que tu petición coincide con la descripción de la skill.

Por ejemplo, si tienes una skill orientada a analizar R8, puedes pedir:

Usa la skill de análisis R8 para investigar por qué esta build release falla tras activar minifyEnabled.

La descripción de una skill es clave: Claude la usa para decidir cuándo cargarla automáticamente. El contenido completo se incorpora solo al activarla, lo que evita llenar el contexto con instrucciones que no aplican a la tarea actual. (code.claude.com)

Paso 3: combina skills con CLAUDE.md

Mantén en CLAUDE.md las reglas que siempre deben cumplirse. Por ejemplo:

# Proyecto Android

- Usa Kotlin y Jetpack Compose para interfaces nuevas.
- La capa `domain` no depende de Android.
- Ejecuta `./gradlew test lint` antes de finalizar cambios relevantes.
- No modifiques versiones del catálogo sin justificarlo.
- Los módulos KMP comparten lógica en `commonMain`.

Después deja los flujos especializados en skills: migraciones, auditorías, generación de changelogs o revisión de módulos.

Usar Android Skills con Codex

Codex también trabaja con el estándar SKILL.md. Una skill contiene un directorio con el archivo principal y, opcionalmente, carpetas como scripts/, references/, assets/ o agents/. El frontmatter debe incluir al menos name y description. (Desarrolladores de OpenAI)

Para un proyecto, Codex busca skills en .agents/skills desde el directorio actual hasta la raíz del repositorio. (Desarrolladores de OpenAI)

Paso 1: instala o copia las skills al repositorio

Ejecuta la instalación de Android CLI desde la raíz del proyecto:

android skills add --all --project=.

Comprueba dónde ha dejado los archivos el instalador. Para Codex, la estructura recomendada del repositorio es:

mi-proyecto/
├── AGENTS.md
├── .agents/
│   └── skills/
│       ├── android-release/
│       │   └── SKILL.md
│       └── kmp-module-review/
│           └── SKILL.md
└── shared/

Paso 2: define reglas persistentes en AGENTS.md

Codex lee AGENTS.md antes de empezar a trabajar. Es el lugar adecuado para documentar cómo se construye, prueba y organiza el repositorio. Las instrucciones más cercanas al directorio actual tienen prioridad sobre las más generales. (Desarrolladores de OpenAI)

Un ejemplo útil para Android y KMP:

# AGENTS.md

## Arquitectura
- `androidApp` contiene la aplicación Android.
- `shared` contiene código Kotlin Multiplatform.
- Las reglas de negocio viven en `shared/commonMain`.
- Las implementaciones de plataforma usan `expect` y `actual` solo cuando son necesarias.

## Validación
- Para cambios en código Kotlin: `./gradlew check`.
- Para cambios Android: `./gradlew :androidApp:assembleDebug`.
- Para cambios en `shared`: `./gradlew :shared:allTests`.

## Restricciones
- No añadas dependencias sin comprobar el catálogo de versiones.
- No cambies APIs públicas sin añadir o actualizar pruebas.

Paso 3: invoca una skill

Codex puede activar una skill por coincidencia con su descripción o de forma explícita desde el selector de skills. En CLI e IDE puedes usar /skills o mencionar una skill con $. (Desarrolladores de OpenAI)

Un prompt práctico sería:

Usa $kmp-module-review para revisar el módulo shared. Detecta dependencias Android en commonMain, APIs no portables y pruebas ausentes. No modifiques archivos todavía: entrega primero un plan priorizado.

Crear una skill propia para Android o Kotlin Multiplatform

Empieza por un problema repetitivo. Una buena skill captura decisiones estables de tu equipo, no preferencias temporales ni instrucciones vagas.

Ejemplos apropiados:

• Revisar que un módulo KMP no filtre dependencias Android a commonMain.
• Preparar una migración de XML a Compose.
• Validar cambios que afectan a R8 y reglas ProGuard.
• Crear una pantalla siguiendo la arquitectura y el design system del proyecto.
• Revisar que una nueva API incluya pruebas unitarias y de UI.

Estructura mínima

Para Codex, crea la skill dentro de .agents/skills. Para Claude Code, usa .claude/skills. Puedes mantener el mismo contenido y duplicarlo, o crear enlaces simbólicos si el entorno del equipo lo permite.

.agents/
└── skills/
    └── kmp-module-review/
        ├── SKILL.md
        └── references/
            └── architecture.md

Ejemplo: skill para revisar módulos KMP

---
name: kmp-module-review
description: Revisa módulos Kotlin Multiplatform cuando se modifique código compartido, dependencias o source sets. Detecta APIs Android en commonMain, dependencias no multiplataforma, acoplamiento de plataforma y pruebas faltantes.
---

## Objetivo

Revisa los cambios del módulo Kotlin Multiplatform sin modificar archivos salvo que el usuario lo pida expresamente.

## Proceso

1. Identifica los archivos modificados en el módulo objetivo.
2. Revisa `build.gradle.kts` y clasifica las dependencias por source set.
3. Comprueba que `commonMain` no dependa de APIs `android.*`, `Context`, `Parcelable`, `ViewModel` de AndroidX ni recursos Android.
4. Verifica que el código específico de Android esté en `androidMain`.
5. Comprueba que los contratos compartidos tengan pruebas en `commonTest` cuando sea viable.
6. Ejecuta las verificaciones disponibles indicadas en `AGENTS.md`.
7. Entrega un informe con severidad, archivo afectado, motivo y propuesta de corrección.

## Criterios de salida

- No afirmes que una verificación se ha ejecutado si no has visto su resultado.
- Diferencia entre errores confirmados, riesgos y recomendaciones.
- Prioriza cambios que rompan compilación, portabilidad o aislamiento entre capas.

## Recursos

Consulta [architecture.md](references/architecture.md) para conocer las excepciones aprobadas por el proyecto.

La descripción no es solo documentación: es el mecanismo de descubrimiento. Debe indicar qué hace la skill, cuándo usarla y, cuando sea útil, cuándo no debe activarse. Codex carga primero el nombre y la descripción; el cuerpo completo de SKILL.md llega cuando selecciona la skill. (Desarrolladores de OpenAI)

Añadir referencias y scripts sin inflar el contexto

Una skill madura no debería convertirse en un documento enorme. Mantén SKILL.md como guía de navegación y mueve el detalle a archivos auxiliares.

kmp-module-review/
├── SKILL.md
├── references/
│   ├── architecture.md
│   ├── approved-libraries.md
│   └── testing-rules.md
└── scripts/
    └── verify-kmp.sh

En Claude Code se recomienda mantener el cuerpo de SKILL.md por debajo de unas 500 líneas y enlazar referencias para que el agente las abra solo cuando sean necesarias. (code.claude.com)

Un script es útil para pasos deterministas. Por ejemplo:

#!/usr/bin/env bash
set -euo pipefail

./gradlew :shared:allTests
./gradlew :androidApp:assembleDebug

No uses scripts para sustituir el juicio del agente. Úsalos para repetir comandos fiables y dejar que la skill explique cuándo deben ejecutarse, cómo interpretar fallos y qué evidencia incluir en el resultado.

Crear skills con asistentes integrados

Claude Code permite crear una skill manualmente añadiendo un directorio y su SKILL.md. También admite archivos de soporte, argumentos, control de herramientas y activación por rutas. (code.claude.com)

Codex incluye $skill-creator, una skill integrada que te guía para definir el objetivo, condiciones de activación y necesidad de scripts. Es una buena opción cuando ya conoces el flujo, pero quieres convertirlo rápidamente en una estructura consistente. (Desarrolladores de OpenAI)

Un prompt de partida para Codex sería:

$skill-creator

Crea una skill para revisar Pull Requests de Android. Debe activarse cuando cambien archivos Kotlin, Gradle o Compose. Tiene que verificar arquitectura, estado en Compose, accesibilidad básica, pruebas y comandos Gradle relevantes. Debe ser de solo lectura y devolver un informe priorizado.

Cómo evaluar si una skill funciona

No des por buena una skill porque el agente la detecta. Evalúa dos cosas por separado:

1. Activación: ¿se selecciona para las peticiones adecuadas?
2. Resultado: ¿el informe, código o validación cumple los criterios definidos?

Crea prompts de prueba con casos positivos y negativos:

Cuando el agente cometa el mismo error varias veces, decide dónde debe vivir la corrección: en AGENTS.md si es una regla permanente del repositorio, o en una skill si pertenece a un flujo concreto.

Recomendaciones finales

Empieza con pocas skills y problemas muy claros. Una colección pequeña, bien activada y versionada junto al código será más útil que decenas de instrucciones genéricas.

Para un proyecto Android/Kotlin Multiplatform, una base sólida suele incluir:

• Un AGENTS.md o CLAUDE.md breve con arquitectura, comandos y restricciones.
• Una skill de revisión KMP.
• Una skill de verificación de builds y pruebas.
• Una skill de revisión de UI Compose y accesibilidad.
• Una skill de release manual, protegida contra activación automática.

Con esta separación, Claude y Codex pueden usar las mismas prácticas de ingeniería sin obligarte a repetirlas en cada conversación.

La clave es diseñar la IA como una capacidad concreta del producto, no como un destino dentro de la navegación. En lugar de preguntar “¿qué quieres preguntarle a Gemini?”, plantea necesidades reales: “resume esta nota”, “extrae los gastos”, “clasifica esta incidencia” o “convierte esta descripción en una tarea”.

Piensa en acciones, no en conversaciones

Un chatbot es una interfaz abierta: el usuario decide qué preguntar y la aplicación debe estar preparada para responder a casi cualquier cosa. Eso añade complejidad, resultados imprevisibles y una carga de diseño importante.

Una integración orientada a tareas limita el problema. La app controla el contexto, el formato esperado y el momento en el que se invoca el modelo.

Algunos casos de uso habituales son:

• Resumir una nota larga antes de guardarla.
• Generar un título para una publicación o documento.
• Extraer fechas, importes o participantes desde texto libre.
• Clasificar una incidencia según prioridad y categoría.
• Reformular una descripción para hacerla más clara.
• Crear etiquetas para contenido generado por el usuario.
• Proponer una lista breve de próximos pasos.

La diferencia parece pequeña, pero cambia toda la experiencia. El usuario no “habla con una IA”: pulsa una acción que resuelve una tarea concreta.

Elige entre inferencia en la nube y en el dispositivo

En Android puedes integrar modelos Gemini en la nube o aprovechar Gemini Nano para ejecutar determinadas tareas localmente. Google recomienda las APIs GenAI de ML Kit como punto de partida para casos de uso integrados en el dispositivo, ya que ofrecen interfaces de alto nivel sobre AICore. (Android Developers)

La elección depende de la experiencia que quieras construir:

No todos los dispositivos tendrán las mismas capacidades locales. Por eso conviene tratar Gemini Nano como una mejora progresiva: úsalo cuando esté disponible y prepara una alternativa cuando no lo esté.

Diseña una salida estructurada

El error más común es pedir texto libre y luego intentar interpretarlo con expresiones regulares. Para una función integrada en producto, Gemini debería devolver datos que tu app pueda consumir con seguridad.

Por ejemplo, una app de gastos puede recibir este texto:

Ayer pagué 24,50 € en una cena con el equipo.

La aplicación no necesita una respuesta conversacional. Necesita algo parecido a esto:

{
  "amount": 24.5,
  "currency": "EUR",
  "category": "restauracion",
  "date": "2026-06-23",
  "description": "Cena con el equipo"
}

Los modelos Gemini permiten solicitar respuestas ajustadas a un esquema JSON, lo que reduce ambigüedad y facilita trabajar con resultados tipados. Esta opción está pensada, entre otros casos, para extracción de datos y clasificación estructurada. (Google AI for Developers)

En Kotlin, el resultado puede representarse con una clase de dominio:

@Serializable
data class ExpenseDraft(
    val amount: Double,
    val currency: String,
    val category: String,
    val date: String?,
    val description: String
)

Después, tu ViewModel puede validar el objeto antes de mostrarlo en pantalla. El usuario sigue teniendo el control: revisa los campos detectados y confirma antes de guardar.

Integra Gemini detrás de una interfaz de dominio

Evita que la UI conozca detalles del SDK, prompts o modelos. La pantalla debería depender de una abstracción orientada al caso de uso.

interface ExpenseExtractor {
    suspend fun extract(text: String): Result<ExpenseDraft>
}

Una implementación concreta puede construir el prompt, invocar el modelo y convertir la respuesta estructurada a ExpenseDraft. La pantalla solo se preocupa por estados como carga, éxito o error.

class CreateExpenseViewModel(
    private val expenseExtractor: ExpenseExtractor
) : ViewModel() {

    var uiState by mutableStateOf(CreateExpenseUiState())
        private set

    fun analyzeDescription(text: String) {
        viewModelScope.launch {
            uiState = uiState.copy(isAnalyzing = true)

            expenseExtractor.extract(text)
                .onSuccess { draft ->
                    uiState = uiState.copy(
                        isAnalyzing = false,
                        amount = draft.amount.toString(),
                        category = draft.category,
                        description = draft.description
                    )
                }
                .onFailure {
                    uiState = uiState.copy(
                        isAnalyzing = false,
                        error = "No se pudo analizar la descripción"
                    )
                }
        }
    }
}

Esta separación facilita pruebas, permite cambiar de proveedor y evita que el modelo se convierta en una dependencia transversal de toda la app.

Haz que la IA sea opcional y reversible

Una buena función de IA no bloquea el flujo principal. El usuario debe poder completar la tarea manualmente aunque Gemini falle, no tenga conexión o devuelva una respuesta poco útil.

En la práctica, esto implica:

• Mostrar resultados como sugerencias editables.
• No guardar cambios automáticamente.
• Mantener formularios y acciones manuales disponibles.
• Ofrecer estados de carga breves y específicos.
• Gestionar errores sin mensajes técnicos.
• Guardar la entrada original para que el usuario no la pierda.

Cuida el prompt como parte del producto

Un prompt útil no intenta ser creativo. Define una tarea, un contexto, restricciones y el formato de salida.

Para clasificar una incidencia, por ejemplo:

Clasifica la incidencia en una de estas categorías:
- facturacion
- acceso
- error_tecnico
- consulta_general

Devuelve únicamente JSON con:
category, priority y summary.

La prioridad debe ser baja, media o alta.
No inventes información que no esté presente en el texto.

Este tipo de instrucciones reduce respuestas decorativas y mejora la consistencia. También conviene incluir ejemplos reales de entradas ambiguas y revisar resultados con datos representativos de tu app.

Las configuraciones de seguridad de Gemini permiten ajustar filtros según las necesidades del producto, pero no sustituyen la validación de negocio ni una buena experiencia de error. (Google AI for Developers)

Mide utilidad, no solo llamadas al modelo

El éxito no es que los usuarios pulsen el botón de IA. Es que terminen antes la tarea para la que abrieron la app.

Mide señales como:

• Porcentaje de sugerencias aceptadas.
• Campos corregidos antes de confirmar.
• Tiempo hasta completar una tarea.
• Tasa de abandono después de una sugerencia.
• Errores de validación derivados de resultados generados.

Con esos datos podrás detectar si Gemini está resolviendo un problema real o simplemente añadiendo una capa llamativa a una interfaz que ya funcionaba.

Conclusión

Integrar Gemini sin convertir tu app en un chatbot significa usar la IA con intención. El modelo debe aparecer cuando puede ahorrar tiempo, reducir fricción o transformar información difícil de procesar manualmente.

Empieza por una sola acción específica, devuelve datos estructurados, mantén al usuario en control y deja que la interfaz actual siga siendo protagonista. Así, Gemini deja de ser una conversación aislada y se convierte en una capacidad útil dentro de tu producto.

Ahí entra en juego la arquitectura Cloud. Ya sea con AWS, Google Cloud, Azure u otros proveedores, disponer de una base backend sólida es determinante para que una aplicación Android, iOS o multiplataforma pueda crecer sin comprometer rendimiento, seguridad ni velocidad de desarrollo.

La aplicación móvil no funciona aislada

En muchos proyectos, la app se conecta a varios servicios remotos. Incluso una aplicación aparentemente simple puede necesitar usuarios registrados, una base de datos, imágenes almacenadas en la nube o notificaciones push.

Una arquitectura Cloud bien planteada define cómo se comunican estas piezas:

• La aplicación móvil consume una API.
• La API aplica reglas de negocio y autorización.
• Los datos se almacenan de forma segura.
• Los archivos se sirven desde un almacenamiento optimizado.
• Los eventos importantes activan procesos asíncronos.
• La monitorización detecta errores y degradaciones.

Esta separación evita que la lógica crítica dependa exclusivamente del cliente móvil. La aplicación puede actualizarse gradualmente, mientras que los cambios urgentes en reglas de negocio o infraestructura pueden desplegarse desde el backend.

Escalabilidad: crecer sin reconstruir el proyecto

Uno de los mayores riesgos de una arquitectura improvisada aparece cuando el producto empieza a recibir usuarios reales. Un backend creado para una demo puede funcionar con cien usuarios, pero fallar cuando llegan miles de peticiones simultáneas.

Los proveedores Cloud permiten escalar recursos según la demanda. Esto puede implicar aumentar instancias de servidor, usar funciones serverless, distribuir contenido mediante una CDN o emplear bases de datos administradas con alta disponibilidad.

Por ejemplo, una app de reservas puede experimentar picos de tráfico durante una promoción. Si toda la infraestructura depende de un único servidor, la aplicación puede volverse lenta o dejar de responder. Con una arquitectura distribuida, es posible absorber ese pico sin intervenir manualmente en cada componente.

Una aproximación habitual es diseñar servicios sin estado. Es decir, que una petición pueda ser atendida por cualquiera de varias instancias disponibles, sin depender de memoria local o sesiones almacenadas en un único servidor.

data class UserSession(
    val userId: String,
    val accessToken: String,
    val expiresAt: Long
)

fun isSessionValid(session: UserSession, now: Long): Boolean {
    return session.accessToken.isNotBlank() && session.expiresAt > now
}

En este ejemplo, la app conserva la información mínima de sesión, pero la validación real de permisos debe resolverse en el backend. Así, cualquier instancia del servicio puede procesar una solicitud de forma consistente.

Seguridad: proteger datos, usuarios y credenciales

Las aplicaciones móviles se distribuyen en dispositivos que no controlamos. Por ese motivo, nunca deben considerarse un entorno seguro para almacenar secretos sensibles, claves privadas o reglas críticas de negocio.

Una arquitectura Cloud robusta ayuda a proteger la información mediante:

• Autenticación centralizada con OAuth 2.0, OpenID Connect o proveedores gestionados.
• Autorización basada en roles, permisos o atributos.
• Cifrado de datos en tránsito y en reposo.
• Gestión segura de secretos y credenciales.
• Auditoría de accesos y cambios relevantes.
• Protección frente a ataques comunes, como abuso de APIs o intentos masivos de inicio de sesión.

La regla práctica es sencilla: la app móvil puede solicitar una acción, pero el servidor debe decidir si esa acción está permitida.

Por ejemplo, no es suficiente ocultar un botón de administración en Android o iOS. Un usuario podría intentar llamar directamente al endpoint. La API debe validar el token, comprobar el rol y confirmar que la operación cumple todas las reglas necesarias.

Rendimiento y experiencia de usuario

La percepción de calidad de una app está muy relacionada con el tiempo de respuesta. Una pantalla puede estar técnicamente bien implementada, pero ofrecer una mala experiencia si necesita esperar demasiado a un servicio remoto.

La arquitectura Cloud afecta directamente a este punto. Algunas decisiones habituales son usar caché para datos consultados con frecuencia, servir imágenes y vídeos desde una CDN, procesar tareas pesadas en segundo plano y acercar los servicios a los usuarios mediante regiones adecuadas.

También es importante diseñar la app para fallar de forma controlada. La conectividad móvil no es estable: el usuario puede perder cobertura, cambiar de red o trabajar temporalmente sin conexión.

Una estrategia de sincronización puede incluir almacenamiento local, reintentos, colas de operaciones pendientes y resolución de conflictos. En Android, por ejemplo, una capa de repositorio puede decidir cuándo leer de caché y cuándo actualizar desde red.

Observabilidad: detectar problemas antes de que afecten al negocio

Cuando una aplicación crece, ya no basta con revisar logs manualmente. Necesitamos entender qué está ocurriendo en producción.

Una arquitectura Cloud madura incorpora métricas, trazas y registros centralizados. Esto permite responder preguntas útiles:

• ¿Qué endpoint está fallando más?
• ¿Cuánto tarda una operación crítica?
• ¿Qué versión de la app genera más errores?
• ¿Hay una región con latencia elevada?
• ¿Qué ocurre cuando falla un proveedor externo?

La observabilidad reduce el tiempo necesario para diagnosticar incidencias. También facilita tomar decisiones basadas en datos, en lugar de depender de intuiciones o reportes aislados de usuarios.

Velocidad de desarrollo y evolución del producto

Una buena plataforma Cloud no solo mejora la operación técnica. También acelera la entrega de funcionalidades.

Los servicios gestionados reducen tareas de infraestructura, como aplicar parches del sistema, crear copias de seguridad o configurar escalado manual. Esto permite que el equipo se concentre en el producto.

Además, una arquitectura modular facilita evolucionar partes concretas. Puede empezar con un backend monolítico bien organizado y, cuando sea necesario, separar procesos como notificaciones, procesamiento de imágenes, facturación o recomendaciones.

No es necesario crear decenas de microservicios desde el primer día. Lo importante es evitar acoplamientos innecesarios y mantener límites claros entre dominios.

Conclusión

Una aplicación móvil no termina en Android, iOS o Kotlin Multiplatform. El cliente es solo una parte de un sistema mayor que debe ser seguro, escalable, observable y capaz de evolucionar.

Invertir pronto en una arquitectura Cloud sólida evita problemas costosos cuando el producto gana usuarios. También mejora la experiencia del equipo, reduce riesgos operativos y permite lanzar nuevas funcionalidades con más confianza.

AWS, Google Cloud y Azure ofrecen herramientas suficientes para construir este tipo de plataformas. La decisión importante no es únicamente qué proveedor elegir, sino diseñar una arquitectura coherente con las necesidades actuales del proyecto y preparada para cambiar cuando el producto lo requiera.

La decisión se simplifica con una pregunta: ¿estás representando un estado actual, un evento que ocurre una vez o un detalle local de la interfaz?

StateFlow encaja con estado observable y persistente. SharedFlow sirve para emisiones o eventos que se distribuyen entre varios consumidores. Compose State, como mutableStateOf, es ideal para estado local gestionado por la propia UI.

La diferencia clave: estado frente a evento

Un estado responde a “¿cómo está la pantalla ahora mismo?”. Por ejemplo:

• La lista de productos está cargando.
• El usuario está autenticado.
• El campo de búsqueda contiene un texto.
• Hay un error visible en pantalla.

Un evento responde a “¿qué acaba de pasar?”. Por ejemplo:

• Mostrar un Snackbar.
• Navegar al detalle de un producto.
• Abrir un selector de archivos.
• Reproducir una animación puntual.

La diferencia importa porque un estado debe poder recuperarse cuando Compose recompone la pantalla o cuando un nuevo colector empieza a observarlo. Un evento, en cambio, normalmente no debería repetirse automáticamente.

Cuándo usar StateFlow

StateFlow es un flujo caliente que siempre conserva un valor actual. Todo nuevo colector recibe inmediatamente ese último valor, por lo que es una opción natural para exponer el estado de pantalla desde un ViewModel. También evita emitir valores consecutivos equivalentes. (Android Developers)

La práctica habitual consiste en mantener un MutableStateFlow privado y exponer un StateFlow de solo lectura.

data class ProductsUiState(
    val isLoading: Boolean = false,
    val products: List<Product> = emptyList(),
    val errorMessage: String? = null
)

class ProductsViewModel(
    private val repository: ProductsRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow(ProductsUiState())
    val uiState: StateFlow<ProductsUiState> = _uiState.asStateFlow()

    fun loadProducts() {
        viewModelScope.launch {
            _uiState.update { it.copy(isLoading = true, errorMessage = null) }

            runCatching { repository.getProducts() }
                .onSuccess { products ->
                    _uiState.update {
                        it.copy(
                            isLoading = false,
                            products = products
                        )
                    }
                }
                .onFailure {
                    _uiState.update {
                        it.copy(
                            isLoading = false,
                            errorMessage = "No se pudieron cargar los productos"
                        )
                    }
                }
        }
    }
}

En Compose, recoge ese flujo de forma segura respecto al ciclo de vida con collectAsStateWithLifecycle().

@Composable
fun ProductsScreen(
    viewModel: ProductsViewModel
) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    when {
        uiState.isLoading -> CircularProgressIndicator()

        uiState.errorMessage != null -> {
            Text(text = uiState.errorMessage)
        }

        else -> {
            LazyColumn {
                items(uiState.products) { product ->
                    Text(product.name)
                }
            }
        }
    }
}

Buenas situaciones para StateFlow

Usa StateFlow cuando el dato:

• Tiene un valor actual relevante.
• Debe sobrevivir a una recomposición o a una recreación de la interfaz.
• Puede necesitarse al volver a entrar en una pantalla.
• Representa el modelo completo o parcial de una UI.

Ejemplos comunes: UiState, sesión de usuario, filtros activos, datos de una pantalla de detalle, preferencias o conectividad.

Cuándo usar SharedFlow

SharedFlow también es un flujo caliente, pero está pensado para difundir emisiones a múltiples colectores. A diferencia de StateFlow, no necesita tener un valor inicial ni representa necesariamente un estado actual. (Kotlin)

Es útil para eventos efímeros: acciones que deben provocar un efecto, no modificar permanentemente la apariencia de una pantalla.

sealed interface ProductsEvent {
    data class ShowMessage(val text: String) : ProductsEvent
    data class NavigateToDetail(val productId: String) : ProductsEvent
}

class ProductsViewModel : ViewModel() {

    private val _events = MutableSharedFlow<ProductsEvent>()
    val events = _events.asSharedFlow()

    fun onProductSelected(productId: String) {
        viewModelScope.launch {
            _events.emit(ProductsEvent.NavigateToDetail(productId))
        }
    }

    fun onRefreshFailed() {
        viewModelScope.launch {
            _events.emit(
                ProductsEvent.ShowMessage("No se pudo actualizar la lista")
            )
        }
    }
}

La UI puede recoger esos eventos dentro de un LaunchedEffect.

@Composable
fun ProductsRoute(
    viewModel: ProductsViewModel,
    onNavigateToDetail: (String) -> Unit
) {
    val snackbarHostState = remember { SnackbarHostState() }

    LaunchedEffect(Unit) {
        viewModel.events.collect { event ->
            when (event) {
                is ProductsEvent.NavigateToDetail -> {
                    onNavigateToDetail(event.productId)
                }

                is ProductsEvent.ShowMessage -> {
                    snackbarHostState.showSnackbar(event.text)
                }
            }
        }
    }

    Scaffold(
        snackbarHost = {
            SnackbarHost(hostState = snackbarHostState)
        }
    ) {
        ProductsScreen(viewModel = viewModel)
    }
}

Precaución con eventos de navegación

SharedFlow no convierte automáticamente los eventos en “exactamente una vez”. La configuración de replay, el buffer y el momento en que empieza el colector afectan a qué emisiones recibe cada consumidor. SharedFlow distribuye los valores entre los colectores activos y puede configurarse para conservar emisiones recientes. (Kotlin)

Para eventos de UI, una configuración frecuente es dejar replay = 0. Así, al recrearse la pantalla, no se reproduce por accidente una navegación o un mensaje ya consumido.

Cuándo usar Compose State

Compose State se refiere a valores observables por Compose, como mutableStateOf, mutableStateListOf o derivedStateOf. Es la mejor herramienta para estado estrictamente local a una composición.

@Composable
fun SearchBar(
    onSearch: (String) -> Unit
) {
    var query by rememberSaveable { mutableStateOf("") }

    OutlinedTextField(
        value = query,
        onValueChange = {
            query = it
            onSearch(it)
        },
        label = { Text("Buscar") }
    )
}

Aquí query pertenece al componente. No hace falta exponerlo desde un ViewModel si no se comparte con otras partes de la app ni representa una decisión de negocio.

Usa remember cuando el valor solo deba durar mientras el composable permanezca en composición. Usa rememberSaveable cuando también deba restaurarse tras cambios de configuración o recreación del proceso cuando el tipo sea guardable.

Buenas situaciones para Compose State

• Estado visual temporal: un menú desplegado, una pestaña seleccionada o una animación.
• Texto de un campo antes de enviarlo al dominio.
• Posición de scroll, foco o visibilidad de elementos.
• Valores derivados solo para optimizar la composición.

Evita almacenar datos de negocio importantes exclusivamente con mutableStateOf dentro de un composable. Al sacar y volver a crear esa pantalla, el estado podría desaparecer.

Guía rápida de decisión

Una arquitectura práctica

Una combinación frecuente y fácil de mantener es esta:

• El ViewModel expone un único StateFlow<UiState> para dibujar la pantalla.
• El ViewModel expone un SharedFlow<UiEvent> para efectos puntuales.
• Los composables usan Compose State para detalles locales de interacción.
• La lógica de negocio y las fuentes de datos permanecen fuera de Compose.

Esta separación reduce errores típicos: mensajes que reaparecen al rotar la pantalla, pantallas que no pueden reconstruirse o estados locales que terminan filtrándose a toda la arquitectura.

La regla final es sencilla: usa StateFlow para lo que es, SharedFlow para lo que ocurre y Compose State para lo que la interfaz necesita recordar localmente.

En 2026, la base recomendada sigue siendo separar claramente la interfaz, los datos y la lógica de negocio. Jetpack Compose encaja especialmente bien con este enfoque porque la UI puede renderizarse como una función del estado, mientras que los ViewModel exponen ese estado y coordinan las acciones del usuario.

Parte de una arquitectura por capas

La estructura más útil para la mayoría de aplicaciones tiene dos capas obligatorias y una opcional:

La capa domain no debe aparecer por obligación. Android recomienda usarla cuando aporta valor real, por ejemplo, cuando una regla de negocio se reutiliza entre varios ViewModel o requiere coordinación entre varios repositorios.

Una estructura inicial puede ser esta:

app/
core/
  common/
  model/
  ui/
  data/
feature/
  home/
  profile/
  settings/

El módulo app compone la aplicación: configura la navegación global, inyección de dependencias y punto de entrada. Cada módulo feature contiene una funcionalidad visible para el usuario, como inicio, perfil o ajustes.

Organiza cada funcionalidad alrededor de su caso de uso

Evita una estructura global basada únicamente en tipos técnicos:

ui/
viewmodel/
repository/
network/

Funciona al principio, pero obliga a recorrer todo el proyecto para entender una pantalla. Es preferible agrupar por funcionalidad y mantener dentro de ella sus elementos relacionados:

feature/
  profile/
    data/
      ProfileRepository.kt
      ProfileRemoteDataSource.kt
    domain/
      GetProfileUseCase.kt
    ui/
      ProfileScreen.kt
      ProfileViewModel.kt
      ProfileUiState.kt

Así, una persona que necesite modificar el perfil puede localizar la mayor parte del código sin saltar por múltiples paquetes.

Usa un flujo de datos unidireccional

Compose funciona mejor cuando la pantalla recibe un estado inmutable y envía eventos hacia el ViewModel.

El ViewModel no debería exponer entidades de red ni detalles de Room directamente. Debe transformar esos datos en un modelo pensado para representar la interfaz, como ProfileUiState.

data class ProfileUiState(
    val isLoading: Boolean = false,
    val userName: String = "",
    val email: String = "",
    val errorMessage: String? = null
)

class ProfileViewModel(
    private val getProfile: GetProfileUseCase
) : ViewModel() {

    private val _uiState = MutableStateFlow(ProfileUiState(isLoading = true))
    val uiState: StateFlow<ProfileUiState> = _uiState.asStateFlow()

    fun loadProfile() {
        viewModelScope.launch {
            runCatching { getProfile() }
                .onSuccess { profile ->
                    _uiState.value = ProfileUiState(
                        userName = profile.name,
                        email = profile.email
                    )
                }
                .onFailure {
                    _uiState.value = ProfileUiState(
                        errorMessage = "No se pudo cargar el perfil"
                    )
                }
        }
    }
}

La pantalla se limita a observar el estado y emitir eventos:

@Composable
fun ProfileRoute(
    viewModel: ProfileViewModel,
    onBack: () -> Unit
) {
    val state by viewModel.uiState.collectAsStateWithLifecycle()

    ProfileScreen(
        state = state,
        onBack = onBack,
        onRetry = viewModel::loadProfile
    )
}

Esta separación simplifica las pruebas: puedes verificar la lógica del ViewModel sin levantar Compose ni depender de una Activity.

Define repositorios como frontera de datos

La capa de datos debe ocultar de dónde procede la información. Un Repository puede combinar API, caché, base de datos local y preferencias sin que la UI tenga que conocer esos detalles.

interface ProfileRepository {
    suspend fun getProfile(): Profile
    suspend fun refreshProfile(): Profile
}

Una implementación puede decidir devolver primero datos locales y actualizar después desde red. El resto de la app depende de la interfaz, no de Retrofit, Room o una API concreta.

Android recomienda que los repositorios centralicen el acceso y los cambios sobre los datos, incluyendo la resolución de conflictos entre fuentes locales y remotas.

Modulariza cuando el proyecto lo justifique

Los módulos Gradle ayudan a reducir acoplamiento, mejorar el aislamiento de funcionalidades y permitir compilaciones más focalizadas. Sin embargo, una modularización excesiva también aumenta la configuración y la complejidad de navegación.

Una distribución práctica es:

:app
:core:common
:core:model
:core:ui
:core:network
:core:database
:feature:home
:feature:profile
:feature:settings

Mantén estas reglas:

• feature puede depender de módulos core.
• Un módulo feature no debería depender directamente de otro feature.
• Los modelos compartidos deben vivir en core:model o en una capa de dominio bien definida.
• El módulo app integra las funcionalidades y decide la navegación de alto nivel.

La guía oficial de Android indica que no existe una única estrategia válida de modularización: debe adaptarse al tamaño, equipo y necesidades reales del proyecto.

Navegación tipada y adaptable

Para aplicaciones nuevas basadas en Compose, Navigation 3 aporta una navegación centrada en Compose, control explícito sobre la pila de navegación y soporte para diseños adaptativos en distintos tamaños de ventana.

Evita rutas construidas manualmente con cadenas:

"detail/$userId"

Prefiere destinos tipados y serializables. Esto reduce errores por parámetros mal escritos o tipos incorrectos y hace que los cambios sean más seguros durante el refactor.

La navegación debe vivir cerca de la capa de aplicación, mientras que cada funcionalidad expone sus destinos y contratos públicos. De este modo, una pantalla no necesita conocer la implementación interna de otra.

Diseña pensando en múltiples dispositivos

Una app Android ya no debería asumir que siempre se verá en un móvil vertical. Compose está orientado a crear interfaces adaptables para distintos tamaños de pantalla.

No dupliques pantallas para tablet, plegables o escritorio. Mantén el mismo estado y adapta la composición visual:

• Barra inferior en pantallas compactas.
• Panel lateral en pantallas medianas o expandidas.
• Dos paneles para listas y detalle cuando haya espacio.
• Navegación independiente del diseño concreto.

La regla es simple: el dominio y el estado no deberían cambiar porque cambie el ancho de la ventana.

Deja preparada la puerta a Kotlin Multiplatform

No todas las apps Android necesitan Kotlin Multiplatform, pero estructurar bien el proyecto facilita adoptarlo más adelante. Google respalda oficialmente KMP para compartir lógica de negocio entre Android e iOS.

Los mejores candidatos para compartir son:

• Modelos y reglas de negocio.
• Casos de uso.
• Clientes de red.
• Repositorios con interfaces comunes.
• Persistencia compatible, como Room para KMP cuando el caso lo requiera.

La UI de Compose para Android puede mantenerse específica de plataforma mientras la lógica central evoluciona en un módulo compartido.

Una estructura que evoluciona contigo

La mejor arquitectura no es la más compleja, sino la que permite añadir una funcionalidad sin romper cinco capas ni duplicar reglas de negocio.

Empieza con UI, datos y ViewModel bien delimitados. Añade dominio cuando haya lógica relevante. Modulariza cuando el proyecto y el equipo lo necesiten. Mantén la navegación tipada, el estado inmutable y las dependencias dirigidas hacia abstracciones.

Con esa base, tu app estará preparada para crecer en funcionalidades, dispositivos y plataformas sin convertir cada cambio en una operación de alto riesgo.

Jetpack Navigation 3 es importante porque replantea esa navegación para el modelo declarativo de Jetpack Compose. En lugar de ocultar el estado de navegación tras un controlador, permite que la aplicación trate el back stack como lo que realmente es: estado observable que define qué contenido debe mostrarse.

Navigation 3 encaja mejor con la filosofía de Compose

Compose describe la interfaz como una función del estado. Cuando cambia el estado, la UI se recompone. Navigation 3 lleva esa misma idea a la navegación: el historial de pantallas es una lista de claves y la interfaz se actualiza al cambiar esa lista.

Esto reduce la distancia conceptual entre el estado de la aplicación y la navegación. No necesitas pensar en la navegación como un sistema separado de la UI; pasa a ser otra parte del estado que puedes modelar, observar y probar.

En términos simples, navegar hacia delante consiste en añadir una clave al back stack. Volver atrás consiste en eliminar la última clave.

data object ProductList
data class ProductDetail(val id: String)

@Composable
fun StoreApp() {
    val backStack = remember {
        mutableStateListOf<Any>(ProductList)
    }

    Button(
        onClick = {
            backStack.add(ProductDetail(id = "android-curso"))
        }
    ) {
        Text("Ver curso")
    }
}

La clave ProductDetail no contiene una pantalla completa ni lógica de presentación. Solo representa el destino y los datos mínimos necesarios para identificarlo. Esta separación ayuda a mantener una arquitectura más clara.

El back stack deja de ser una caja negra

Con enfoques tradicionales, el historial de navegación suele estar gestionado internamente por un NavController. Eso resulta cómodo en escenarios simples, pero puede dificultar casos avanzados: restaurar flujos concretos, coordinar varias columnas o mantener estados independientes por sección.

Navigation 3 adopta otra postura: la aplicación es propietaria del back stack. La librería observa ese estado y lo representa mediante NavDisplay.

Esta decisión es relevante porque aporta control real. Puedes decidir dónde vive el back stack, cómo se conserva, cómo se restaura y qué reglas de negocio afectan a cada transición.

Por ejemplo, una aplicación puede evitar que un usuario abandone un formulario con cambios sin guardar:

fun navigateBack(
    backStack: MutableList<Any>,
    hasPendingChanges: Boolean,
    onShowDiscardDialog: () -> Unit
) {
    if (hasPendingChanges) {
        onShowDiscardDialog()
    } else {
        backStack.removeLastOrNull()
    }
}

La navegación no queda desligada de la lógica del producto. Puede responder a permisos, cambios pendientes, autenticación o reglas de negocio sin forzar soluciones indirectas.

Facilita interfaces adaptativas para móviles, tablets y plegables

La importancia de Navigation 3 no se limita a cambiar de pantalla. También está pensada para mostrar más de un destino del back stack al mismo tiempo.

Este enfoque encaja especialmente bien con interfaces adaptativas. En un móvil compacto puedes mostrar una lista y, al abrir un elemento, navegar a una pantalla de detalle. En una tablet, la lista y el detalle pueden convivir en dos paneles sin tener que inventar una arquitectura de navegación paralela.

El back stack sigue expresando la intención del usuario: ha abierto una lista y ha seleccionado un detalle. Lo que cambia es la forma de presentar esa información según el tamaño de ventana disponible.

Esto evita diseñar una aplicación “para móvil” y después añadir excepciones para pantallas grandes. La navegación puede partir del mismo estado y adaptar su representación visual.

Mejora la modularización de aplicaciones grandes

En proyectos pequeños es habitual definir todas las rutas en un único archivo. En productos reales, esa estrategia acaba generando módulos centrales demasiado grandes, dependencias innecesarias y conflictos entre equipos.

Navigation 3 organiza el contenido navegable mediante entradas. Cada funcionalidad puede aportar sus propias entradas y resolver sus claves sin que toda la aplicación conozca los detalles internos de cada módulo.

Una estructura posible sería:

• feature-home: define HomeRoute y su contenido.
• feature-courses: define CourseListRoute y CourseDetailRoute.
• feature-profile: define ProfileRoute.
• app: compone las entradas de todos los módulos y gestiona el flujo global.

Esta separación ayuda a que una funcionalidad evolucione sin convertir el grafo de navegación en un punto de acoplamiento masivo.

Hace más natural la persistencia del estado

Los usuarios esperan volver a una app y encontrarla donde la dejaron. También esperan que una rotación de pantalla no reinicie su flujo actual.

Como Navigation 3 trabaja con claves, y no con pantallas completas almacenadas en el historial, resulta más directo guardar y restaurar el back stack. Una clave como ProductDetail("android-curso") tiene significado fuera de la composición actual: identifica un destino que la app puede reconstruir después.

Esto también obliga a tomar una buena decisión de diseño: el back stack debe contener referencias ligeras, no objetos pesados ni estados efímeros de pantalla.

No elimina la necesidad de diseñar bien la navegación

Navigation 3 ofrece más control, pero ese control también exige disciplina. Tener acceso directo al back stack no significa que cualquier composable deba modificarlo libremente.

Conviene encapsular las acciones de navegación en eventos claros, como onCourseSelected, onProfileRequested u onBackPressed. De ese modo, la UI expresa intenciones y una capa superior decide cómo actualizar el estado de navegación.

La librería tampoco sustituye decisiones de experiencia de usuario. Sigue siendo necesario definir correctamente qué destinos son principales, cuándo conservar una pestaña, cómo manejar enlaces profundos y qué comportamiento debe tener el botón Atrás.

Una base preparada para el futuro de Compose

Jetpack Navigation 3 es importante porque acerca la navegación a la forma de pensar que ya usamos en Compose: estado explícito, UI declarativa y composición flexible.

Para aplicaciones sencillas, el cambio puede parecer pequeño. Para productos con múltiples flujos, módulos, pantallas grandes o requisitos de restauración de estado, el beneficio es mayor: menos soluciones especiales, mejor control arquitectónico y una relación más directa entre la intención del usuario y la interfaz que se muestra.

Adoptarlo no consiste solo en cambiar una dependencia. Consiste en tratar la navegación como estado de primera clase dentro de la aplicación.

La consecuencia para los equipos Android es importante: además de construir buenas pantallas, habrá que diseñar funciones que puedan ser descubiertas, invocadas y ejecutadas de forma segura desde asistentes, widgets, coches, relojes y otros puntos de entrada.

Android se convierte en un sistema de inteligencia

Una de las ideas centrales del evento es la transición de Android desde un sistema operativo tradicional hacia un “sistema de inteligencia”. Gemini podrá automatizar determinadas tareas dentro de las aplicaciones, mientras que las nuevas AppFunctions permitirán a las apps exponer acciones y capacidades al sistema.

Estas funciones se apoyan en un enfoque compatible con Model Context Protocol, de modo que una aplicación puede ofrecer herramientas, datos y operaciones a agentes del dispositivo de una forma más estructurada. Por ejemplo, una app de viajes podría exponer acciones para consultar una reserva, mostrar una tarjeta de embarque o buscar el estado de un vuelo.

data class FlightStatus(
    val code: String,
    val departureTime: String,
    val gate: String?,
    val delayed: Boolean
)

class FlightRepository {
    fun getStatus(code: String): FlightStatus {
        return FlightStatus(
            code = code,
            departureTime = "18:45",
            gate = "B12",
            delayed = false
        )
    }
}

El reto no consiste solo en conectar una API de IA. Las acciones deben ser pequeñas, verificables y seguras. Una buena AppFunction debería responder a una intención concreta, aplicar permisos correctos y evitar operaciones irreversibles sin confirmación del usuario. Google ha presentado estas APIs como una vista previa experimental, por lo que conviene explorarlas en prototipos antes de convertirlas en una dependencia crítica de producción. (Android Developers)

Gemini Nano y la IA en el dispositivo

La IA local sigue ganando importancia. Google mostró la vista previa de Gemini Nano 4 mediante AIcore, junto con mejoras en las APIs generativas de ML Kit. El objetivo es facilitar experiencias con menor latencia, mayor privacidad y menos dependencia de una conexión constante.

Este enfoque encaja especialmente bien en funciones como clasificación de texto, resúmenes de contenido local, asistencia contextual, extracción de información y procesamiento de cámara o multimedia. No todas las tareas requieren enviar datos a un servidor remoto, y la arquitectura de una app debería decidir dónde ejecutar cada modelo según coste, privacidad, calidad y disponibilidad.

Compose First: el futuro de la interfaz Android

Google ha confirmado una dirección muy explícita: Jetpack Compose pasa a ser el estándar principal para la interfaz, mientras que Views entra en modo de mantenimiento. Esto no significa que las apps existentes deban reescribirse de inmediato, pero sí que las nuevas guías, librerías y capacidades se orientarán primero a Compose. (Android Developers)

Para muchos equipos, la estrategia más razonable será migrar de forma incremental. Las nuevas pantallas, componentes reutilizables y experiencias adaptativas son buenos candidatos para Compose, mientras que las vistas heredadas pueden mantenerse hasta que exista una razón de producto o mantenimiento para sustituirlas.

@Composable
fun BookingCard(
    destination: String,
    date: String,
    modifier: Modifier = Modifier
) {
    Card(modifier = modifier.fillMaxWidth()) {
        Column(modifier = Modifier.padding(16.dp)) {
            Text(
                text = destination,
                style = MaterialTheme.typography.titleLarge
            )
            Text(
                text = date,
                style = MaterialTheme.typography.bodyMedium
            )
        }
    }
}

El foco ya no es solo crear interfaces bonitas. Compose facilita construir diseños que se adapten a pantallas grandes, plegables, ventanas redimensionables y superficies emergentes.

Android 17 exige aplicaciones más adaptativas

Android 17 introduce cambios relevantes para quienes preparan la compatibilidad con API 37. Entre ellos destacan la redimensionabilidad obligatoria en pantallas grandes, el endurecimiento del audio en segundo plano, protecciones para códigos SMS OTP, transparencia de certificados activada por defecto y restricciones de acceso a la red local. (Android Developers)

La adaptación deja de ser un extra para tablets y foldables. Google plantea un estándar “adaptive first”: los usuarios alternan entre móvil, tableta, portátil, coche, reloj y experiencias XR durante el día. Una app que solo funciona bien en un teléfono vertical corre el riesgo de ofrecer una experiencia incompleta.

La recomendación práctica es revisar tres áreas:

• Diseños con WindowSizeClass y paneles adaptativos.
• Navegación que soporte pantallas grandes y multitarea.
• Pruebas en emuladores de tablet, plegables y ventanas redimensionables.

Productividad asistida por agentes en Android Studio

La edición de Android Studio presentada en I/O 2026 refuerza el desarrollo asistido por agentes. Android CLI permite que herramientas de IA interactúen con tareas específicas de Android, como analizar archivos, resolver símbolos, detectar advertencias o renderizar previews de Compose. (Android Developers)

También se presentó la posibilidad de generar aplicaciones Android nativas desde Google AI Studio a partir de una descripción. El flujo incluye generación de proyectos Kotlin con Compose, vista previa en emulador integrado, despliegue en dispositivos físicos y exportación del proyecto para abrirlo en Android Studio. (Android Developers Blog)

Esto puede acelerar prototipos, pruebas de concepto y generación de pantallas repetitivas. Sin embargo, no elimina la necesidad de revisar arquitectura, seguridad, accesibilidad, pruebas y comportamiento offline. La IA puede producir código rápidamente; el equipo sigue siendo responsable de decidir qué código merece llegar a producción.

Rendimiento, memoria y herramientas de calidad

Google también puso el foco en la eficiencia. Android 17 incorpora límites de memoria basados en la RAM del dispositivo para reducir problemas de fugas y consumo excesivo. En paralelo, Android Studio incorpora R8 Configuration Analyzer, una herramienta para identificar reglas keep demasiado amplias que impiden eliminar y optimizar código. (Android Developers)

Este tipo de mejora tiene impacto directo en el usuario: menos tamaño de descarga, arranques más rápidos, menor consumo de memoria y menos cierres inesperados. La optimización ya no debería reservarse para la fase final del proyecto.

Más superficies: widgets, coches, Wear OS y Play

La presencia de una app ya no termina al cerrar su actividad principal. Google impulsa Jetpack Glance como un modelo compartido para widgets de móvil, Wear OS y coches, con RemoteCompose para crear experiencias ligeras y expresivas en superficies remotas. (Android Developers)

En Google Play, la distribución también cambia. Las aplicaciones podrán ganar visibilidad dentro de Gemini, y Google planea facilitar el descubrimiento de contenidos mediante sugerencias y enlaces profundos hacia experiencias concretas de la app. Además, Play Shorts introduce un formato de vídeo vertical para mostrar el producto directamente en la tienda. (Android Developers)

Qué priorizar después de Google I/O 2026

La mejor respuesta a estas novedades no es adoptar todo de golpe. Conviene priorizar una hoja de ruta realista:

1. Revisar la preparación para Android 17 y API 37.
2. Definir Compose como opción predeterminada para desarrollo nuevo.
3. Auditar layouts para tablets, plegables y ventanas grandes.
4. Identificar una o dos acciones candidatas para AppFunctions.
5. Medir tamaño, arranque y consumo de memoria con R8 y perfiles reales.
6. Evaluar cómo widgets, Gemini y Google Play pueden mejorar el descubrimiento de la app.

Google I/O 2026 no redefine Android por una sola API, sino por la combinación de IA contextual, interfaces adaptativas, automatización del desarrollo y presencia en más dispositivos. El valor diferencial seguirá estando en construir experiencias claras, rápidas y confiables, pero ahora deberán funcionar también como parte de un ecosistema inteligente.