This is a submission for the Google I/O 2026 Challenge: Explore Google I/O 2026
At Google I/O 2026, Google made it official: Jetpack Compose is now the standard for Android UI development. Views is in maintenance mode.
Not deprecated. Not dead. Maintenance mode. But let's not pretend that distinction softens the message: Google is done adding capabilities to the old system. Everything new — every layout primitive, every performance improvement, every accessibility feature — goes into Compose only.
I've been writing Android UIs for years. Here's my honest reaction.
What "Maintenance Mode" Actually Means
What will still happen:
- Critical bug fixes
- Security patches
- The existing Views API surface stays stable — your
RecyclerViewandConstraintLayoutcode won't break
What will stop happening:
- New layout primitives
- Performance improvements beyond critical regressions
- Integration with new Jetpack APIs
- New Material Design components
The new stuff that ships at I/O 2026 illustrates the gap already. The Grid API — a powerful 2D layout primitive for screen-level architecture — is Compose only. The CameraXViewfinder Composable, the Media3 AI Effects library, and the Gemini integration surfaces in Android Studio are all Compose-first.
If you're building in Views, you can still build. But the platform is no longer building for you.
The New Compose-First World
I/O 2026 shipped a set of Compose updates that show where the platform is headed:
Grid API — A 2D layout API that handles screen-level composition without the overhead of a scrollable list. This is the replacement for complex ConstraintLayout nesting that developers have been wanting for years. Available in Compose only.
Shared element debug tools — Debugging shared element transitions was a pain point. New tooling in the April '26 release (core modules v1.11) makes them inspectable and testable.
Jetpack Glance unification — Glance now covers widgets across mobile, Wear OS, and cars in a single API surface. If you've been maintaining separate widget code for each platform, this is meaningful.
Trackpad events — Small but important for tablet and ChromeOS development. Compose gets it. Views doesn't.
Who This Hurts and Who This Doesn't
It doesn't hurt: Teams that already adopted Compose. Google's own data says the majority of new Android apps started in the last two years are Compose-first. If you're in that group, I/O 2026 is a good news story — the platform is investing heavily in your foundation.
It hurts most: Large apps with deep Views investments — banking apps, enterprise apps, anything with 5+ years of fragment-based architecture. These teams face a genuine question: migrate incrementally, or accept growing technical debt as the platform moves away from their stack.
The migration story is real. Compose interoperability (ComposeView inside fragments, AndroidView inside Compose) lets you migrate screen by screen. Google's new Migration Assistant in Android Studio — which can port apps from Views to Compose — is the clearest signal yet that Google is trying to make the path tractable. But "tractable" and "easy" aren't the same thing.
The Honest Take on Compose's Maturity
Compose was genuinely rough at 1.0. Lazy layouts had performance cliffs. Custom drawing was underdocumented. The interop story with existing libraries was complicated.
In 2026, most of those early pain points are resolved. Lazy performance is solid. The drawing APIs are well-documented. The library ecosystem — Coil, Accompanist patterns now in core, Material3 — is mature. Using Compose for a new screen today isn't an adventure. It's just writing UI code.
The one area that still genuinely lags: deeply custom UI components. If you need pixel-perfect rendering that deviates significantly from Material Design, Compose's Canvas API is capable but the learning curve is steeper than the old View.onDraw() approach. This is a small fraction of development work for most teams, but it's worth knowing before you're mid-migration.
What To Do If You Have a Large Views Codebase
Don't panic-migrate. Maintenance mode means stable, not broken. Your existing code works. A panic migration of a large app produces worse code than a planned migration.
Start new screens in Compose. Every new screen or feature is an opportunity to write Compose. Over 12–18 months, this naturally migrates the active parts of your app.
Use the Migration Assistant on your most annoying screens. Not as a bulk-migration tool, but as a way to evaluate the output quality and understand what the automated path looks like in your specific codebase.
Watch the Grid API. If you have complex dashboard or catalog layouts that stretch ConstraintLayout to its limits, Grid API is worth a spike. That class of layout gets meaningfully better in Compose.
Accept that some legacy screens can stay in Views indefinitely. A payment flow that's been stable for four years and has extensive test coverage doesn't need to be migrated immediately. The maintenance mode guarantee means it won't break. Prioritize migration by code churn, not by age.
The Bigger Picture
Google's "Compose-first" declaration is the platform finally saying out loud what's been true for two years: Compose is the Android UI system. Views is the legacy API.
For developers starting new projects, this is just clarity. For developers maintaining large legacy codebases, it's a planning input: the technical debt from staying on Views isn't accumulating linearly, it's accelerating as the distance between the platform's investment and your stack grows.
The good news is the migration tooling has never been better, the interop story is solid, and Compose's maturity means the destination is worth reaching. The window for a graceful migration is now — before the gap between Views capabilities and Compose capabilities becomes wide enough to feel urgent.
Links: Android UI Development is Compose First — Android Developers Blog · Jetpack Compose April '26 Release Notes · Google I/O 2026 Android Sessions