Android development is now Compose First | Skip<br>Skip to content

Android development is now Compose First

Jun 4, 2026 - 8 min read - 1529 words

Compose-First Android Development<br>Section titled “Compose-First Android Development”

Last week at Google I/O, the Android team announced (to audience cheers1) that all new Android UI will be Jetpack Compose going forward. The Android is Compose-first ↗ page on the developer site now states2:

Jetpack Compose is Android’s declarative UI toolkit, built for modern user interfaces, with dynamic data, rich graphics, and beautiful animations. It’s replacing the View toolkit, which has served Android development well for years, but was not designed for the latest demands and best practices.

The same page declares that the old View system is, without quite saying “deprecated”, moribund technology:

We now consider the View toolkit (for example, classes in android.widget such as TextView and ListView) to be in maintenance mode — this means that it will only receive highly critical fixes.

The companion announcement covers the Jetpack libraries and Android Studio’s UI tooling as well: the View-based libraries are frozen at “critical fixes only”, and any new tooling in Android Studio will target Compose only. Existing View-era tools such as the Layout Editor and Navigation Editor will continue to receive only critical fixes in maintenance mode, but will not be enhanced and improved going forward.

For anyone tracking the Android platform over the last several years, this should come as no surprise: Compose has been the recommended toolkit for new development since 2021. But it is the clearest signal yet that the long transition is now effectively over. Compose is the future, and the Android View system — like UIKit on iOS — is legacy technology.

This is the right outcome for Android developers. Compose is a modern toolkit that embraces the industry’s trend towards a declarative state-driven user interface paradigm. It is where the platform’s investment is going, and it is what new APIs will be built around.

It is also an outcome that validates Skip’s unique approach. Skip has been “Compose-first” on Android since the day we first shipped, both in Skip Lite (where we transpile SwiftUI into idiomatic Compose) and in Skip Fuse (where we bridge native Swift to Compose directly). When you write List, NavigationStack, or TextField in your SwiftUI source, the Android side of your app builds a real Jetpack Compose tree using the same components that a Kotlin Android developer would reach for. There is no parallel widget hierarchy or custom renderer, and no second-class “Compose interop” mode. The Compose tree is the Android UI, just as the SwiftUI tree is the iOS UI.

SwiftUI-First iOS Development<br>Section titled “SwiftUI-First iOS Development”

Apple issued a symmetric declaration four years earlier in their Platforms State of the Union3:

The best way to build an app is with Swift and SwiftUI.

One of the fundamental principles of Skip is that it simply doesn’t exist on iOS. The Apple side of a Skip app is the same Xcode project and App struct and SwiftUI view hierarchy that an iOS-only team would produce. While we do have plenty of platform and integration frameworks that help provide unified API surfaces between iOS and Android libraries, the Skip toolchain itself, on iOS, is invisible at runtime. Skip’s build plugin assembles and launches the Android counterpart of your app side-by-side with the iOS build, but it does not wrap or intermediate your SwiftUI views. When you write Text("Hello") in a Skip project, the iOS binary contains a Text("Hello") — nothing more and nothing less.

This is what we mean when we say Skip is not an intermediation layer on iOS. There is no abstraction between your code and Apple’s frameworks for a SwiftUI compiler to optimize through, and no compatibility layer for an OS upgrade to break. You are not running a “Skip-flavoured” SwiftUI: you are running SwiftUI.

A practical consequence showed up last summer, when Apple unveiled their new Liquid Glass design language at WWDC 2025. Regardless of how one feels about this aesthetic redesign, every existing Skip app automatically picked it up the day the first developer beta shipped. There was no Skip update required and no SwiftUI compatibility layer to upgrade. Liquid Glass is implemented inside Apple’s frameworks, and Skip apps use Apple’s frameworks directly; therefore Skip apps look like the rest of iOS automatically. The same will be true for the next design refresh, and the one after that. This sort of guaranteed future-compatibility is essential for teams that prioritize harmony with the platform and alignment with the first-party SDKs.

Why other cross-platform frameworks struggle to keep up<br>Section titled “Why other cross-platform frameworks struggle to keep up”

The Compose-first Android announcement, along with last year’s Liquid Glass unveiling, are both instructional opportunities to...