Android è ufficialmente Compose-first. La tua app basata su View è ora codice legacy.

Al Google I/O 2026 di questa settimana, Google ha preso la decisione che gli sviluppatori Android attendevano da anni. Jetpack Compose è ora il modo ufficiale e predefinito per costruire interfacce Android. Il toolkit View, il mondo di TextView, ListView, ConstraintLayout e Fragment su cui girano ancora la maggior parte delle app in produzione, è in modalità manutenzione. Riceve solo correzioni critiche e nient'altro.

Google è stata attenta alle parole. Le View non sono deprecate e non c'è una data di rimozione. Ma «modalità manutenzione» ha un significato preciso in questo contesto. Nessuna nuova funzionalità, nessuna nuova API, e tutti i nuovi strumenti UI di Android Studio sono congelati, inclusi il Layout Editor e il Navigation Editor. Le nuove librerie Jetpack, la documentazione, i codelab e gli esempi saranno Compose-first. La linea guida ufficiale è diretta: costruisci le nuove UI in Compose e converti le schermate esistenti man mano che le modifichi.

Da anni sviluppiamo app Android native in ambito sanitario, IoT ed e-commerce, e la maggior parte di esse è partita come progetto basato su View. Per molti team, quindi, questa è una decisione concreta, non solo un titolo. Ecco come la interpretiamo.

Il rischio pratico non è che la tua app si rompa. Non accadrà. Il rischio è più lento di così. Il tuo codebase si sposta silenziosamente su un'isola senza supporto. Ogni nuova funzionalità Android, ogni nuovo componente Material, ogni miglioramento agli strumenti presuppone ora Compose. Un team ancora su View nel 2027 non è in pericolo, sta solo pagando una tassa sempre più pesante in workaround e funzionalità mancanti.

L'istinto di «riscrivere l'intera app» è sbagliato. Abbiamo visto riscritture UI big-bang bloccarsi per mesi e portare regressioni, e Compose è costruito per l'approccio opposto. ComposeView e AndroidView permettono a Compose e View di girare sulla stessa schermata, anche nello stesso layout. Puoi convertire una schermata, poi un componente, e gli utenti non vedranno mai la differenza. Compose 1.11, mostrato anch'esso all'I/O, ha migliorato le prestazioni specificamente per queste schermate ibride.

C'è anche un aspetto legato alle assunzioni che è facile trascurare. Compose è ciò che i nuovi sviluppatori Android imparano oggi. I candidati se lo aspettano, e la documentazione attuale lo dà per scontato. Un codebase ricco di View diventa sempre più difficile da gestire dal punto di vista del personale, e quel costo resta invisibile finché non sei tre mesi dentro a una ricerca.

Google ha anche mostrato un Android Studio Migration Assistant che utilizza un agente AI per portare le schermate, e AI Studio può ora generare app Compose da un prompt. Questi strumenti aiuteranno. Ma dalla nostra esperienza nell'inserire agenti AI in pipeline di delivery reali, la lezione si ripete: un agente che converte una schermata è utile solo se uno sviluppatore che conosce Compose rivede l'output. Tratta una migrazione generata come una bozza, non un risultato. I team che ci rimettono sono quelli che lasciano che il volume di conversioni superi la loro capacità di revisione.

Se gestisci un'app Android basata su View, fai una cosa concreta questo trimestre. Scegli la tua prossima schermata genuinamente nuova e costruiscila in Compose, dall'inizio alla fine, con l'interoperabilità configurata correttamente. Non un prototipo, una schermata che effettivamente rilasci. Quell'unico esercizio ti dirà più di qualsiasi documento di pianificazione: come il tuo team gestisce lo stato di Compose, dove il tuo design system ha bisogno di equivalenti Compose, come regge il tuo setup di build e test. Poi stabilisci una regola semplice. Ogni schermata che tocchi in modo sostanziale viene convertita. Costante e noioso, e si accumula.

Un'ultima cosa per i team che gestiscono sia iOS che Android. Il Compose-first su Android si allinea con la posizione che SwiftUI occupa già su iOS. Entrambe le piattaforme si aspettano ora un layer UI dichiarativo e basato sullo stato. Se stai pianificando lavori nativi iOS e Android, questo è un buon momento per allineare la tua architettura in modo che le due piattaforme ragionino allo stesso modo sull'interfaccia. Rende i codebase più facili da gestire e da revisionare, qualcosa che abbiamo visto ripagare nei nostri progetti mobile passati.

Non è un'emergenza. È una direzione. La piattaforma UI di Android ha ora un default chiaro, e il costo di ignorarlo non è un crash. È un accumulo lento di attrito.

Se uno stack di schermate Android basate su View senza un piano di migrazione chiaro ti suona familiare, parliamone.