# ComposeCookBook: a Jetpack Compose sample collection you can read screen by screen

> ComposeCookBook is an MIT-licensed Android sample app that gathers Jetpack Compose widgets, layouts, animations, adaptive scaffolds and full demo UIs in one Gradle project. It is a reference to read and copy from, not a library to depend on.

**Gurupreet/ComposeCookBook** — A Collection on all Jetpack compose UI elements, Layouts, Widgets and Demo screens to see it's potential

- Repository: https://github.com/Gurupreet/ComposeCookBook
- Stars: 6,879 · Forks: 860
- Language: Kotlin
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/gurupreet-composecookbook

## What ComposeCookBook collects, and who it is written for

ComposeCookBook is a single Android project that gathers Jetpack Compose UI elements, layouts, widgets and demo screens so you can see how each one is built. The README describes it as "A Collection of all Jetpack compose UI elements, Layouts, Widgets and Demo screens to see it's potential." The audience is Android developers who already know Kotlin and want working composable source rather than prose documentation.

The repository is organised by topic rather than by feature: top-level directories include animations/, app/, components/, data/, demos/, templates/ and theme/. That layout tells you what the project is for. You open a directory, find the screen that matches the effect you want, and read the composable that produces it. There is no published artifact, no Maven coordinate and no API contract. The README's contribution notes ask that a newly added widget or UI element be added to the Widget Screen, which confirms the Widgets screen is the index of building blocks.

It is a poor fit if you want a library you can bump in a version catalog. Nothing here is versioned for consumption; the release tags describe the sample app itself.

## How the sample is organised: modules, version catalog and buildSrc

The build is a standard Gradle multi-module Android setup. The README states that dependencies and versions live in the Gradle version catalog at gradle/libs.versions.toml, and that shared module configuration (convention plugins, SDK levels) lives in buildSrc. In practice that means a screen's dependencies are declared once in the catalog and referenced by alias, and the compileSdk, minSdk and similar values are set centrally rather than repeated in each module's build file.

The README pins the toolchain: Android Studio Ladybug or newer, JDK 17, targeting AGP 8.7 and Kotlin 2.1. The badge in the README names Jetpack Compose BOM 2024.12.01. The release list shows 2.0.0, described as "Compose modernization", published 2026-09-15, and a staging build tagged latest-master from 2026-09-12. The last push to the repository was on 2026-09-19.

The demo apps are the part that shows integration rather than isolated composables. The README lists apps with API, Retrofit, Room, Flow and LiveData integration, including a CryptoApp built with MVVM and a MovieApp built with MVI. Those two are the useful reference points if you want to see where state lives and how it reaches a composable. Note that they do not share one architecture: the point of the collection is coverage, not consistency, and copying patterns from two different demos into one app will produce a mixed codebase.

## Installing ComposeCookBook and opening the Widgets screen

There is no package to install. You clone the repository and open it in Android Studio. The README asks for Android Studio Ladybug or newer and JDK 17, and states the project targets AGP 8.7 and Kotlin 2.1.

```bash
git clone https://github.com/Gurupreet/ComposeCookBook.git
cd ComposeCookBook
```

After the clone, open the folder in Android Studio and let Gradle sync. The README points at gradle/libs.versions.toml for dependency versions and buildSrc for shared module configuration, so those two places are where to look if the sync fails on a version mismatch.

One demo needs credentials. According to the README, the MoviesApp demo needs a TMDB API key, added to the git-ignored local.properties as tmdbApiKey, or exported as TMDB_API_KEY. The README is explicit that without the key the demo still builds but the movie lists stay empty, so an empty list is not a build failure.

```properties
tmdbApiKey=YOUR_KEY
```

The README also links a prebuilt debug APK from the latest-master release, so you can look at the screens on a device before touching the source. For a first read of the code, start on the Widgets screen, which the README describes as the showcase of all the available components for building UI, then move to the home screen for layouts, modifiers and simple list views.

## Adaptive layouts and the large-screen scaffolds

The adaptive layout section is the most concrete part of the README and the easiest to evaluate. It names two APIs. NavigationSuiteScaffold switches between a bottom bar, a rail and a drawer based on window size. ListDetailPaneScaffold produces a two-pane layout on tablets and foldables, and the README says to find it under "Adaptive UI" on the home screen.

That is a useful pair to study together, because they cover different halves of the same problem. NavigationSuiteScaffold answers where navigation controls go; ListDetailPaneScaffold answers how list and detail content share a wide window. If you are porting a phone-only Compose app to foldables, these two screens are the reason to open the repository at all.

The limitation is that the README documents these in two bullet points. It does not state which window size classes trigger which navigation form, whether the state is preserved across a size change, or how the scaffolds behave in multi-window mode. You have to read the composables to answer those questions, which is consistent with the rest of the project: the code is the documentation.

## Where ComposeCookBook stops being the right tool

The collection is wide, and width comes at a cost. The README's Coming Soon section lists a clean architecture sample with coroutines and advanced canvas drawing as features that "will be available in coming weeks". Until those land, the repository has no single reference implementation of a layered architecture, so if that is what you need, this project does not currently provide it.

Version drift is the second constraint. The README names AGP 8.7, Kotlin 2.1 and Compose BOM 2024.12.01. Compose moves quickly, and sample code written against one BOM can fail to compile or behave differently against another. Nothing in the repository states a compatibility policy for older or newer toolchains.

The third issue is that a sample app is not a test suite. The README points at UI tests as a topic to study, but the project makes no claim about coverage, and there is no published support commitment. If you need a dependency with a release cadence, an issue triage process and semantic versioning, you are looking at the wrong kind of project. Treat ComposeCookBook as reading material with a runnable APK attached, and vendor whatever you copy.

## ComposeCookBook against the official Compose samples

The obvious alternative is Google's own compose-samples repository, which the README links under Official Documentations alongside the Compose Pathway and the Jetpack Compose documentation. The difference in approach matters more than the overlap.

Google's samples are maintained by the team that ships Compose, so they tend to track the current BOM and to demonstrate the recommended pattern for a given feature. ComposeCookBook is one developer's collection, and its value is breadth and immediacy: a long list of UI elements, list scroll animations, shimmer lists, carousel and bottom sheet templates, and complete demo UIs such as Spotify, Instagram, Gmail, TikTok and a meditation screen, all in one repository with a single build.

If you want the canonical way to do something, read Google's samples and the Compose Pathway first. If you want a broad set of screens to scroll through and lift composables from, ComposeCookBook covers ground the official samples do not attempt, and the MIT licence makes reuse straightforward. The two are complements rather than substitutes, and the README treats them that way by linking the official material from its own documentation section.

## Licence, releases and what an upgrade costs

The repository is MIT licensed. That is permissive: you can copy composables into a commercial app, modify them and ship them, provided the licence text and copyright notice travel with the code. This is not legal advice, and the practical point is narrower: MIT removes the licensing question but not the maintenance question, because copied code becomes yours the moment it lands in your module.

The release history shows the shape of the upgrade cost. Version 1.0.2 is dated 2021-09-17, and 2.0.0, labelled "Compose modernization", is dated 2026-09-15. That is a long gap between major tags, and the 2.0.0 label indicates a toolchain jump rather than incremental additions. A third tag, latest-master, is described as a staging build, so it should not be treated as a stable reference.

In practice, upgrading means re-reading the demo you copied and re-checking it against the current Compose BOM, since the README names BOM 2024.12.01 and does not state a support window. The last push was on 2026-09-19, so the repository is not dormant, but the release tags are the only signal about how often the sample is brought forward.

## Conclusion

Adopt ComposeCookBook when you want runnable Compose source for widgets, list animations, adaptive layouts or full demo screens, and you are ready to keep it pinned to one version of the Compose BOM. Skip it if you need a versioned library, a maintained API surface or a single canonical architecture: the demos deliberately mix MVVM, MVI and plain composables, and the README itself leaves the clean architecture sample under Coming Soon. Before copying anything, check gradle/libs.versions.toml for the exact Compose BOM and AGP versions the code was written against, and confirm the MoviesApp demo needs a TMDB API key in local.properties before its lists will show data.

## FAQ

### What does ComposeCookBook use Jetpack Compose for?

It is a collection of Jetpack Compose UI elements, layouts, widgets and demo screens, gathered so you can see how each is built. The README describes it as a collection to see Compose's potential, and the code is organised by topic into directories such as components, demos, templates and theme.

### Is ComposeCookBook better than building Android UI with XML?

The repository takes no position on that comparison; it only contains Compose code. What it does show is the range Compose covers in one project, from widgets and layouts to animations, adaptive scaffolds and full demo UIs such as Spotify, Instagram and Gmail, which is the practical way to judge the declarative approach for yourself.

### What is the ComposeCookBook playground?

The repository works as a playground in the sense that it ships a sample app you can build and run. The README links a prebuilt debug APK from the latest-master release, so you can browse the screens on a device before opening Android Studio and reading the composables.

## Sources

- [Gurupreet/ComposeCookBook on GitHub](https://github.com/Gurupreet/ComposeCookBook)
- [Issues](https://github.com/Gurupreet/ComposeCookBook/issues)
- [License: MIT](https://github.com/Gurupreet/ComposeCookBook/blob/master/LICENSE)
- [README](https://github.com/Gurupreet/ComposeCookBook/blob/master/README.md)
- [Releases](https://github.com/Gurupreet/ComposeCookBook/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gurupreet-composecookbook