5 Years of Jetpack Compose: Views Enter Maintenance Mode, and What That Actually Means for Your App

The Android team published a retrospective yesterday marking five years since Jetpack Compose's first public alpha. It's the kind of post that's easy to scroll past — anniversary announcements usually read as marketing. This one had something concrete buried inside it: the Views toolkit has entered maintenance mode. No new features going forward, bug fixes only. That is not marketing fluff. That is a product decision, and it changes the migration calculus for every Android team still running View-based UI.

I've been building on Android long enough to remember when Compose was a fringe experiment from a Google I/O talk that nobody was quite sure would ship. I shipped my first Compose screen in production in 2022, rewrote Nodat's entire UI by 2023, and haven't written a new XML layout for anything since. So when Google formally closes the chapter on Views, I have opinions about what that means — and they're not the same as "drop everything and migrate today."

What "Maintenance Mode" Actually Means

This is the part that needs a plain-language translation, because "maintenance mode" means different things in different contexts. For the Android Views toolkit, Google's definition is precise: security patches and critical bug fixes will continue, but no new API surface is coming. If you file a feature request for the View system today, it will not be implemented.

This is not a deprecation notice. They're not removing TextView or RecyclerView next year. Your existing View-based app will continue to build and run. The platform APIs your custom views rely on — Canvas, Paint, onDraw(), measure/layout/draw — are part of the OS, not the toolkit layer, and aren't going anywhere near-term.

What it does mean is that the divergence between the two worlds will now compound at an accelerating rate. Every Compose release ships new primitives — the Grid API, SwipeToReveal, MeshGradient, shared element transitions, the Compose-native predictive back integration — and Views gets none of it. Material 3 Expressive, which Google announced as the current design system target, is Compose-first. The XR platform (Jetpack XR SDK, Galaxy Glasses) is Compose-only. Wear OS updates land in Glance and Compose for Wear. If you're building something that needs to look current and work across form factors, the gap only widens from here.

The 68% Number Deserves Context

Google cited that 68% of the top 1,000 Play Store apps now use Compose in production. That's an impressive adoption curve for a UI toolkit — most platform-level rewrites take a decade to reach that kind of penetration. But the number needs unpacking before you use it to justify a migration budget.

"Uses Compose" covers a wide range: one screen in Compose inside an otherwise fully View-based app counts. A lot of teams adopted Compose incrementally exactly the way Google recommended — start with a new feature screen, migrate standalone components, leave the legacy screens alone until you touch them anyway. If you're in that camp, you're already in the 68%, and the question isn't whether to start, it's how fast to finish.

The remaining 32% skews toward older, larger codebases with heavy custom View infrastructure — sophisticated touch handling, hardware-accelerated canvas drawing, highly customized recycler view pools, that kind of thing. These aren't teams that missed the memo. They made deliberate calls about migration cost vs. benefit, and some of those calls were correct given what Compose looked like in 2022. The maintenance mode announcement is new information that should feed back into those calculations.

Where Compose Now Runs

One thing the five-year retrospective made clear is how far the Compose target has expanded beyond the phone screen I originally learned it on:

• Mobile Android — the obvious one, current stable is Compose 1.11 with 1.12 imminent
• Wear OS v3 — Glance for watch widgets, Compose for Wear OS for app UIs
• Android TV — Compose for TV, stable
• App widgets — Glance 1.3.0 with health data APIs (I wrote about this recently)
• Android XR — Jetpack XR SDK 1.0.0 just hit beta, Compose is the primary API surface
• Display glasses — Compose Glimmer for Samsung Galaxy Glasses, announced at Unpacked last week

Material Design is now officially Compose-first, which means the design language you're building toward is being defined in Compose terms first and translated backward into View-equivalent implementations second — when at all. Material 3 Expressive's new components like FloatingToolbar, WavyProgressIndicator, and shape morphing for chips don't have View equivalents and won't get them.

This is the platform convergence argument that's been theoretical for a few years now becoming concrete. One Compose codebase can, in principle, target phone, tablet, foldable, watch, TV, and XR headset. Views never had that story and never will.

The Migration Argument Shifts — But Doesn't Become Simple

Here's where I want to push back on the take I see a lot in dev Twitter and Slack threads: "maintenance mode = migrate now, no debate." The timing argument is more nuanced than that, and getting it wrong in either direction costs money.

The case for migrating sooner

If you're hiring, the talent pool argument gets real fast. Junior and mid-level Android developers entering the market in 2026 are primarily learning Compose. If your codebase is 80% XML and custom views, you're narrowing the pool of people who can ramp up quickly, and you're creating a knowledge asymmetry where your oldest senior devs are the only ones who understand the trickier parts of the View hierarchy. That's a long-term team risk that doesn't show up on a quarterly roadmap.

The other case is platform features. If your product roadmap includes large-screen or foldable support, Wear OS, or any kind of XR play, the cost of doing that on Views is not zero — you'd be doing extra adaptation work to compensate for APIs that were designed for Compose and bolted onto Views as an afterthought, if at all.

The case for being deliberate

Migrating UI is not cheap, and "maintenance mode" doesn't mean your Views stop working. If you're running a stable, well-tested View-based codebase with no plans for new form factors, the business case for an immediate wholesale rewrite is weak. What you should be doing is: stop writing new XML. Every new feature screen goes in Compose. Every screen you touch for other reasons gets Composified while you're in there. The migration happens at the margin without blocking the roadmap.

What you should avoid is the trap of doing nothing because the legacy stuff still runs, then waking up in two years with a codebase where the oldest screens are completely alien to your junior devs and the newest platform features are unavailable to you.

What the Next Five Years Look Like

The Compose investment curve from Google is steep and accelerating, not flattening. Between the R8 coroutines optimization that ships automatically with AGP 9.2.0, the Grid API and SwipeToReveal in Compose 1.12, Material 3 Expressive graduating components to stable, and the XR platform being Compose-native from day one — the advantage of being on the new system over the maintained-but-frozen old one is only going to grow.

The five-year anniversary also coincides with something harder to quantify: the mental model maturity of the community. The confusing parts of Compose — stability, derivedStateOf, LaunchedEffect lifetimes, snapshot state, the subtleties of recomposition scope — have been thoroughly documented, blogged, talked about, and in many cases fixed or improved. New developers joining in 2026 have better educational resources than we did when learning Compose in 2021. That matters for team velocity.

I don't think there's a world where, five years from now, any serious Android developer is writing new XML layouts. The trajectory is as clear as it's been since Compose 1.0 shipped — it's just that maintenance mode makes it official rather than implicit. If your team hasn't had the "Compose migration strategy" conversation seriously, the anniversary announcement is as good a forcing function as any to have it.

The good news is you don't have to pick a start date on a calendar and block out a quarter. You just have to stop adding to the legacy pile — and that decision costs nothing to make today.