Jetpack Compose 1.11.0 landed on 22 April 2026, shipped in the Compose BOM 2026.04.01. It is a bigger release than the version number suggests: two new layout systems, a new approach to component styling, and a declarative way to adapt to window size and device posture. Most of the new APIs are marked experimental, but they are the direction Compose is heading, and a few of them replace patterns you have probably been hand-rolling for years.
Grid: two-dimensional layout without a scrolling list
Until now, building a genuine two-dimensional layout in Compose meant either nesting Rows inside Columns and fighting to keep columns aligned, or reaching for LazyVerticalGrid — a scrolling, virtualising component — purely because you wanted its column behaviour. Grid fixes that. It gives you tracks, gaps, row and column spans, and flexible "Fr" units borrowed from CSS grid. Because it is not a lazy component, it measures all its children, which is exactly what you want for screen-level scaffolding: a dashboard, a settings screen, a form. Reach for Grid when the number of items is known and bounded; keep LazyVerticalGrid for long, scrolling collections.
FlexBox: wrapping, growing and shrinking
FlexBox handles the case Grid does not: content whose size you do not control. It supports wrapping, grow and shrink factors, and multi-axis alignment. The obvious use is a tag or chip cloud that must wrap onto however many lines the content needs, but it is equally useful for toolbars and filter bars that have to survive translation into a language with much longer words. If you have ever written a custom Layout just to make chips wrap, you can delete it.
The Styles API: state-based styling with transitions
Component customisation in Compose has historically meant passing a long tail of colour and shape parameters, or wrapping a component to intercept its state. The new Styles API lets you describe how a component looks in each of its states — pressed, focused, disabled, hovered — and animates the transitions between them for you. The practical benefit is that visual state stops leaking into your business logic. Your ViewModel exposes "isEnabled"; the style decides what disabled looks like and how it fades in.
MediaQuery: adaptive UI as a declaration, not a calculation
MediaQuery lets you adapt declaratively to window size, keyboard type, and device posture — including tabletop mode on a foldable, where the device is half-open and resting on a surface. This matters more in 2026 than it did in 2024, because Android 17 removes the ability for apps to opt out of resizing on large screens. Code that branches on a hardcoded width threshold will not survive contact with a Googlebook, a tablet, or a half-folded phone. MediaQuery is how you express that intent once instead of scattering width checks through your composables.
Trackpad events are now mouse events
A quieter change with real consequences: trackpad events are now reported as PointerType.Mouse rather than as touch. Two-finger swipes and pinch gestures are supported on API 34 and above, and there is a new performTrackpadInput testing API to drive them from instrumentation tests. If your gesture code branches on pointer type — and a lot of drag-and-drop code does — check it. Behaviour that looked correct on a phone can invert on a Chromebook or a tablet with a keyboard case.
Testing: the v2 coroutine APIs are now the default
The v2 testing APIs are now the default and the v1 APIs are deprecated. The substantive change is the move from UnconfinedTestDispatcher to StandardTestDispatcher, which more closely mimics production scheduling. Expect this to surface race conditions that your test suite was previously papering over. That is the point, but budget time for it: a suite that goes red after upgrading Compose has usually been red in production all along.
Plan the Compose 1.12 upgrade now
Compose 1.12.0 will require compileSdk 37 and Android Gradle Plugin 9. Neither is a small bump, and AGP major versions have a habit of breaking build scripts and third-party Gradle plugins. Do not couple that migration to a feature release. Move compileSdk and AGP in an isolated pull request, get the build green, then take the Compose upgrade separately. Teams that bundle the two spend a week bisecting which change broke the build.
What I would adopt first
If you ship one thing from this release, make it MediaQuery — it is the cheapest insurance against the Android 17 resizability changes. Grid is the next-best return on effort, because it deletes real code. I would hold off on the Styles API in a large codebase until it stabilises out of experimental, since a breaking change to a styling API touches every component you own. Experimental in Compose has historically meant "the shape will change", not "this will be deleted", but the migration cost still lands on you.