kizitonwose/Calendar: the date picker that gives you the whole grid

Three artifacts, chosen by platform

The library publishes three Maven coordinates and the distinction between them is about date APIs and platforms, not about capability. `com.kizitonwose.calendar:compose` is the Compose artifact for Android projects and uses the `java.time` APIs. `com.kizitonwose.calendar:compose-multiplatform` targets Compose Multiplatform projects, uses the kotlinx-datetime library, and supports Android, iOS, js, WasmJs and Desktop. `com.kizitonwose.calendar:view` is the View system artifact for Android, also on `java.time`, and the README notes it can exist alongside the Android Compose artifact in the same project if needed.

That last point matters for incremental migration. A team with an established View-based Android app can adopt the View artifact without a Compose rewrite, and add the Compose artifact later in the same module.

Adding the Android variants is two lines:

dependencies {
  // The view calendar library for Android
  implementation("com.kizitonwose.calendar:view:<latest-version>")

  // The compose calendar library for Android
  implementation("com.kizitonwose.calendar:compose:<latest-version>")
}

The multiplatform artifact goes in the common source set instead:

commonMain.dependencies {
  // The calendar library for compose multiplatform projects
  // Supports Android, iOS, js, WasmJs and Desktop platforms
  implementation("com.kizitonwose.calendar:compose-multiplatform:<latest-version>")
}

Latest versions are published to Maven Central under the group `com.kizitonwose.calendar`, and snapshots of the development version live in the Central Portal snapshots repository.

Desugaring is the one real setup hurdle

There is exactly one required setup step, and it exists only if your app's `minSdkVersion` is below 26. The `java.time` classes were added in Java 8, which Android supports natively from SDK 26, so older targets need Java 8+ API desugaring. The README also requires Android Gradle plugin 4.0.0 or higher for this to work, and the same `compileOptions` block sets `coreLibraryDesugaringEnabled true` along with Java and Kotlin compatibility at 1.8.

The block also contains a comment that earns its place: multiDex must be enabled, and the README marks that as required only if your `minSdkVersion` is below 21. So a project on SDK 23 with 2.10.0 does not need it, while a project that had to desugar down to 21 or below does.

Beyond that, the README states two version constraints that are easy to miss and expensive to discover late. There is a Compose UI version compatibility section, and the released 2.10.0 bumped Compose UI to 1.10.1 on Android and 1.10.0 on Multiplatform, Kotlin to 2.3.0 and the Android Gradle plugin to 8.13.2. The same release raised `minSdk` to 23 to align with the androidx libraries. So the current floor is SDK 23, and the desugaring step applies to anything below 26 rather than to the full historical range.

If your project cannot move its Compose version, the release notes are the place to check which combination was shipped together.

The feature list is really a list of decisions you have to make

The README's feature checklist reads like a marketing list until you notice that almost every entry corresponds to a question an app team has to answer anyway. Week, month, or year modes. Single, multiple, or range selection. Whether some dates should be disabled and whether the calendar has boundary dates at all. Which day appears first in the week. Whether scrolling runs horizontally or vertically.

Then there are the three that make this library different from a date picker. Custom date view or composable means the individual day cell is yours. Custom calendar view or composable means the surrounding grid is yours. Headers and footers can be attached per year, per month or per week, which is what you need when the calendar sits inside a screen that already has its own title area.

The heatmap calendar is listed as suitable for showing how data changes over time, with GitHub's contribution chart given as the example. That is a genuinely different use case from date selection, and it is the feature that would justify pulling the library into a project that has no picker at all.

Scrolling to a date, a week, a month or a year works through swipe actions or programmatically, and the last checklist item is the important one: use all RecyclerView or LazyRow or LazyColumn customizations, since the calendar extends RecyclerView for the view system and uses LazyRow and LazyColumn for Compose. The project's summary of its own philosophy is that the library provides the logic and you provide the views or composables.

The sample project carries the documentation

The README is explicit that it is important to check out the sample app, with the reason given: most techniques you would want to implement are already done in the examples. That is a candid statement about where the documentation lives.

There are two samples. The Android sample app has a downloadable APK, and the multiplatform sample is viewable online in a browser, which is the fastest way to see what the library looks like on iOS and Desktop without installing anything. Both sample source trees are linked from the README.

One detail there is worth flagging so it does not confuse you. The download link for the Android sample app points at an asset tagged 2.5.4, while the newest release published to the repository is 2.10.1. The APK is a snapshot from an earlier version than the current library, so treat it as an illustration rather than a reference build.

The repository tree supports the same conclusion about where the logic lives. Alongside `sample/` there are separate `core/`, `data/`, `view/`, `compose/` and `compose-multiplatform/` modules, a `buildSrc/` directory for build logic, and a `docs/` directory. Date range handling and the selection model are most likely in `core/` and `data/`, with the two rendering targets consuming them.

What recent releases actually changed

The published releases are small and specific, which tells you the API surface has settled. Version 2.10.1, from 2026-03-28, implemented five scroll properties across all the calendar state classes: `canScrollForward`, `canScrollBackward`, `lastScrolledForward`, `lastScrolledBackward` and `scrollIndicatorState`. Adding these to the state objects rather than to the composables is what lets a parent scrollbar or a scroll-aware container respond to the calendar.

Version 2.9.1, released the same day as 2.10.0 on 2026-01-17, added a week container parameter to the week calendar. That is a small addition with a large consequence: a week calendar previously laid itself out with no place for a caller-supplied wrapper, which is what you need to add padding, a background or a click handler around it.

The 2.10.0 release is the dependency one, and it pairs the version bumps with a behaviour change by raising `minSdk` to 23.

This repository is not archived, the last push was on 2026-08-13, and at 5,601 stars with 583 forks and 10 open issues it is one of the more actively maintained Android date libraries. Ten open issues against that star count is a low backlog, and it is a reasonable signal that the project gets to its issues.

How this compares with the platform date picker

The comparison to make is against what you get for free. The Material date picker in Compose and the framework DatePicker dialog in the View system both ship with the platform, follow the system theme automatically, and handle accessibility and locale rules that are genuinely hard to reimplement. Neither lets you change what a day cell looks like beyond a few documented slots.

If your requirement is a working date field, use the platform picker and stop reading. This library earns its dependency in three situations. The first is a calendar that is part of the screen design rather than a dialog, such as a booking flow or a scheduler where the month grid is the interface. The second is a heatmap calendar, since nothing in the platform covers that. The third is Compose Multiplatform, where the Android artifact cannot help you and the artifact here supports Android, iOS, js, WasmJs and Desktop from one common source set.

The cost is real and worth stating plainly. You own accessibility semantics for your day cells, you own the visual states for selected, disabled and today, and you own the layout decisions. The library supplies the date maths, the range logic and the scrolling, and stops there.

Editorial conclusion

This library is a good fit when a stock Material date picker would dictate the design. Because the calendar extends RecyclerView in the view system and composes LazyRow or LazyColumn in Compose, you keep the scrolling behaviour and item customisation you already know instead of adopting a widget whose internals you cannot reach. The three artifacts are chosen by platform rather than by preference, and only the multiplatform one uses kotlinx-datetime, so migrating an existing Android app means nothing changes. The setup burden is the desugaring step for anything below SDK 26 and the requirement to think about your first day of week and selection mode up front. The sample project is where the real answers are; the README covers installation and nothing else about the API.

Frequently asked questions

Official sources

1. Issues
2. kizitonwose/Calendar on GitHub
3. License: MIT
4. README
5. Releases