ComposeViews fills the gap between Android View widgets and Compose Multiplatform

One dependency line for Android, iOS, web and desktop

The pitch of ComposeViews is portability through a single artifact. The project describes itself as applicable to Compose Multiplatform, with supported targets of Android, iOS, web on both js and Wasm js, and desktop on Windows, Linux and macOS. The primary language is Kotlin, and the repository topics spell out the reach: android, compose-multiplatform, kmm, ios, web, wasm and desktop.

Adding it is a single Gradle dependency in your app or common module, using the build.gradle.kts file:

dependencies {
    ...
    implementation("io.github.ltttttttttttt:ComposeViews:$version")//this, such as 1.6.11.2
}

The coordinate is io.github.ltttttttttttt:ComposeViews, and the version badge points at Maven Central, so the library is consumed the same way as any other artifact rather than by cloning the repository. The repository also holds a jitpack.yml, a composeview.jks keystore and separate app modules for android_app, desktop_app, iosApp, js_app and wasm_app, which is the shape you would expect from a project that tests the same components against every target it claims to support.

For a team that already owns a Compose Multiplatform setup, the interesting question is what the library saves you from writing, not how it is packaged.

The version table is the real cost of using it

ComposeViews is versioned against the Compose toolchain, and the project publishes a support table that anyone adopting it has to read. The current row pairs the ComposeViews version with a Jetpack Compose version of 1.11.1, a Compose Multiplatform version of 1.11.1 and a Kotlin version of 2.3.20 or later. Below that, 1.10.0.2 maps to 1.10.0 and 1.10.0 on Kotlin 2.1.10+, and 1.9.0.4 maps to 1.9.0 and 1.9.0 on the same Kotlin floor.

The older rows show a different pattern. 1.7.0.3 requires Compose 1.7.1 with Compose Multiplatform 1.7.0 on Kotlin 2.0.0+, 1.6.0.4 needs Compose 1.6.1 and Compose Multiplatform 1.6.0 and pins Kotlin at 1.9.22 exactly, and the 1.5.x line sits on Kotlin 1.9.0 and 1.9.20. The 1.4.0.14 row goes back to Kotlin 1.8.20.

That table is the sharpest edge in the project. A library that rides on Compose's own versioning can only move as fast as its dependency allows, and a team on an older Kotlin cannot simply take the newest artifact. The recent releases show the same rhythm, with 1.11.1.2 published on 2026-06-14 and 1.11.1.1 two days earlier, and 1.10.0.2 back on 2026-03-18.

Nine documented component groups, and a longer catalogue

The README lists the views in nine groups: ComposePager, Banner, PagerIndicator, ImageBanner, RefreshLayout together with PullToRefresh and VerticalRefreshableLayout, FlowLayout, ValueSelector together with DateSelector, MenuFloatingActionButton, and a group combining ChainScrollableComponent, ScrollableAppBar and SwipeToDismiss.

The repository description is broader still, adding an image viewer, a ZoomLayout, a Star Bar, a Date Selector described as covering a time selector and date picker, and the phrase and more. So the published catalogue is larger than the numbered list in the documentation, and the list in the documentation is what a new user can rely on being described.

The API shape is consistent across the components, and reading the parameter documentation for the pager shows the pattern. ComposePager takes a page count, a modifier, a ComposePagerState, an orientation, a flag for whether the user can scroll, a page cache for the number of pagers cached on the left and right sides, a scrollable interaction source, a pager key, a clip flag and a content transformation:

@Composable
fun ComposePager()

Banner takes the same core set and adds an autoScroll flag and an autoScrollTime interval, which is the difference the documentation draws between the two: Banner is described as a ComposePager that can auto scroll.

State objects and flow types are how the components stay reactive

The parameter names reveal that these are not stateless layout helpers. ComposePager takes a ComposePagerState, and PagerIndicator takes two Flow values, one for the index of the selected indicator and one for the offset percentage of the selected indicator. The indicator also takes an indicatorItem and a selectIndicatorItem, so the selected and unselected appearances are separate composables the caller supplies.

The text variant follows the same idea with more knobs. TextPagerIndicator takes the text list, a font size and a selectFontSize for the text indicator, a textColor and a selectTextColor, a selectIndicatorColor, an onIndicatorClick handler, a margin, an orientation and a userCanScroll flag, while the plain PagerIndicator takes a size for the number of indicators, the two indicator items, a margin, an orientation and its own userCanScroll flag.

The performance hint in the pager documentation is worth repeating for anyone porting from a ViewPager: the pagerKey parameter is described as using a key to improve performance, reduce recombination, and achieve the same effect as the key parameter on LazyColumn items. Both ComposePager and Banner carry that parameter, which tells you the library expects identity to be handled explicitly rather than left to the caller's data model.

The catalogue covers the components Compose leaves out

The clearest way to place ComposeViews is against what the Compose standard library already gives you. Pager, LazyColumn and the Material set cover scrolling, lists and basic layout on every Compose target. What they do not cover is the set of patterns that grew out of the Android View world and were never ported: a refresh layout with a pull to refresh gesture, a flow layout for wrapping children, a chain scrollable component, a swipe to dismiss, an app bar that participates in nested scrolling, a zoomable image viewer, a star bar, and a date selector.

Those are exactly the entries in the list, and the naming in the repository description maps each one to a familiar concept: a pager equivalent to the Android ViewPager, a scrollable app bar described as a nested scroll view, a date selector described as a time selector and date picker, and a swipe to dismiss.

The alternative approach is to write those components yourself in commonMain. That is what the library exists to avoid, and it is the honest comparison: for one platform, writing a flow layout is an afternoon, while a cross-platform zoom layout with pinch gestures is not. The cost of taking the library instead is the version matrix and the fact that the detailed documentation lives on a separate site rather than in the repository, so the README alone will not get you through the parameters of every component.

Apache-2.0 with a Chinese README and an external docs site

The licence is Apache-2.0, recorded in a LICENSE file at the top of the repository and in an Apache 2 badge, so using these components inside a proprietary application carries the usual permissive terms rather than copyleft obligations. The code is published as a library on Maven Central under the io.github.ltttttttttttt group, which is what makes the dependency line above work from a standard Gradle repository.

Documentation is split three ways. The English README sits at the root, a Chinese version sits beside it as README_CN.md, and a header line links out to a detailed documentation site hosted on GitHub Pages at sakurajimamaii.github.io/ComposeViewsDocs. Samples live in the repository itself, with per-component sample links pointing at Kotlin files in common_app, such as ComposePagerActivity.kt, BannerActivity.kt, PagerIndicatorActivity.kt and TextPagerIndicatorActivity.kt, and an Android demo APK is published from md_resource.

On maintenance, the last push was on 2026-06-19, and the release history shows 1.11.1.2 on 2026-06-14 and 1.11.1.1 on 2026-06-13, so the tags and the branch are close together. The build also leans on a buildSrc directory, a gradle directory with a wrapper, and a kotlin-js-store, which is the standard arrangement for a project that has to produce JS and Wasm output as well as native binaries.

Editorial conclusion

Adopt ComposeViews if you are shipping one Compose Multiplatform codebase to several targets and would otherwise reimplement a pager, a banner, a date selector or a zoomable image viewer for each platform. Do not adopt it if you only target Android, where the standard Compose libraries and AndroidX already cover most of this ground. Before adding the dependency, check two things: the version support table in the project documentation, because each ComposeViews release is pinned to a specific Compose, Compose Multiplatform and Kotlin combination, and whether the components you need are actually in the published list, since the documented set covers nine groups and the full catalogue is longer than what the README spells out.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. ltttttttttttt/ComposeViews on GitHub
4. README
5. Releases