Android is officially Compose-first. Your View-based app is now legacy code.

At Google I/O 2026 this week, Google made the call Android developers have been circling for years. Jetpack Compose is now the official, default way to build Android UI. The View toolkit, the TextView, ListView, ConstraintLayout, and Fragment world that most production apps still run on, is in maintenance mode. It gets critical fixes and nothing else.

Google was careful with the wording. Views are not deprecated, and there is no removal date. But "maintenance mode" has a precise meaning here. No new features, no new APIs, and any new Android Studio UI tooling is frozen, including the Layout Editor and Navigation Editor. New Jetpack libraries, documentation, codelabs, and samples will be Compose-first. The official guidance is direct: build new UI in Compose, and convert existing screens as you touch them.

We have shipped native Android apps in healthcare, IoT, and e-commerce for years, and most of them started as View-based projects. So this is a real decision for a lot of teams, not a headline. Here is how we read it.

The practical risk is not that your app breaks. It will not. The risk is slower than that. Your codebase quietly drifts onto an unsupported island. Every new Android capability, every new Material component, every tooling improvement now assumes Compose. A team still on Views in 2027 is not in danger, it is just paying a widening tax in workarounds and missing features.

The "rewrite the whole app" instinct is the wrong one. We have watched big-bang UI rewrites stall for months and ship regressions, and Compose is built for the opposite approach. ComposeView and AndroidView let Compose and Views run on the same screen, even in the same layout. You can convert one screen, then one component, and users never see the seam. Compose 1.11, also shown at I/O, improved performance specifically for these hybrid screens.

There is also a hiring angle that is easy to miss. Compose is what new Android developers learn now. Candidates expect it, and current documentation assumes it. A View-heavy codebase is getting harder to staff, and that cost stays invisible until you are three months into a search.

Google also previewed an Android Studio Migration Assistant that uses an AI agent to port screens, and AI Studio can now generate Compose apps from a prompt. These will help. But from our own work putting AI agents into real delivery pipelines, the lesson keeps repeating: an agent that converts a screen is only useful if a developer who knows Compose reviews the output. Treat a generated migration as a draft, not a result. The teams that get burned are the ones that let conversion volume outrun their review capacity.

If you maintain a View-based Android app, do one concrete thing this quarter. Pick your next genuinely new screen and build it in Compose, end to end, with the interop wired up properly. Not a spike, a screen you actually ship. That single exercise tells you more than any planning document: how your team handles Compose state, where your design system needs Compose equivalents, how your build and test setup copes. Then set a simple rule. Every screen you substantially touch gets converted. Steady and boring, and it compounds.

One more thing for teams that run both iOS and Android. Compose-first on Android lines up with where SwiftUI already sits on iOS. Both platforms now expect a declarative, state-driven UI layer. If you are planning native iOS and Android work, this is a good moment to align your architecture so the two platforms reason about UI the same way. It makes the codebases easier to staff and easier to review, something we have seen pay off across our past mobile projects.

This is not an emergency. It is a direction. Android's UI platform has a clear default now, and the cost of ignoring it is not a crash. It is a slow buildup of friction.

If a stack of View-based Android screens with no clear migration plan sounds familiar, let's talk.