CoolMallKotlin: a modular Compose e-commerce app kept as a learning reference

A complete shopping flow, labelled feature by feature

CoolMallKotlin, whose Chinese name is Qing Shang Cheng, is an open source e-commerce learning project built with Kotlin and Jetpack Compose, and the readme states that the core features are essentially complete. It covers a full commerce flow including user authentication, product display, shopping cart and order payment.

The most useful thing in the readme is the feature status list, because it tells you exactly what exists. Each feature carries one of five labels, defined in the readme: a feature that is fully implemented and usable, one that is basically implemented but needs further refinement, one that is implemented but needs performance or experience optimisation, one where only the page UI exists and the logic does not, and one that is not yet developed.

That distinction is rare and valuable. On this project, the main module has home, category, cart and me all marked as fully implemented. The auth module has login, account login, register and SMS login implemented, but password recovery is marked as page only. The user module has address list, address detail and browsing history implemented, while the personal centre is page only. The order module lists order list, confirm order, order detail, payment, refund, review and logistics as implemented.

Reading those labels before you clone anything saves you from assuming that a screen you can see in the screenshots has working logic behind it. The readme also notes that because there are many feature modules, not every screen is shown in the screenshots, and you are pointed to the downloadable demo to see the full application.

The module split: app, feature, core and a separate build-logic

The repository layout is the architecture lesson. At the top level there is an app/ directory for the application module, a feature/ directory holding the feature modules by business area, a core/ directory for shared code, a build-logic/ directory, a template/ directory, and the standard Gradle files including settings.gradle.kts, build.gradle.kts, gradle.properties, gradlew and gradlew.bat.

The feature modules are organised by domain rather than by screen, with main covering the four top-level tabs, auth covering the five login and registration screens, user covering profile, addresses and history, order covering the seven order screens, and goods covering product search and product detail. The domain split is the point: an order screen should not reach into the auth module to read a token, and the module boundary is what makes that enforceable.

The build-logic/ directory is the piece that distinguishes this from a tutorial project assembled in a weekend. Convention plugins live there, which is the mechanism for encoding the project rules, like which module types exist and what a feature module must contain, in the build rather than in a document that goes stale. The template/ directory is the other half of the same idea, holding scaffolding for new modules.

The readme says the project follows the architecture design of Now in Android, the Google reference app, and describes the approach as modular design with Clean Architecture and highly decoupled feature modules. Taking an existing reference architecture and applying it to a domain that is not a news app is the specific contribution here, and it is a different contribution from writing another news app.

The stack, with the versions pinned in the readme

The technical stack is documented with explicit version numbers, which is what makes this usable as a reference rather than just a demo.

The core is Kotlin 2.3.20 with 100 percent Kotlin development, Jetpack Compose 2026.03.01 as the declarative UI framework, MVVM plus Clean Architecture as the pattern, Hilt 2.59.2 for dependency injection, and Coroutines with Flow 1.9.0 for asynchronous and reactive work.

The functional modules use Navigation3 with Lifecycle ViewModel Navigation3 at 1.0.1 and 2.10.0, Kotlinx Serialization 1.10.0 for JSON, Retrofit with OkHttp at 3.0.0 and 5.3.2 for networking, Coil Compose 2.7.0 for image loading and caching, Lottie Compose 6.7.1 for After Effects animations, and XXPermissions 28.0 for runtime permission requests.

Storage is Room 2.8.4 for the SQLite database and MMKV 2.4.0 for high performance key value storage, a split that reflects a real decision, since MMKV is a memory mapped key value store and is not a relational database.

The tooling table lists Timber 5.0.1 for logging, Chucker 4.3.1 for network request inspection, LeakCanary 2.14 for memory leak detection, XXPermissions 28.0 for dynamic permissions, and JUnit 4.13.2 for unit and UI tests.

One detail in the feature list deserves attention: complete test coverage is marked as planned work, and large screen support for tablets and foldables is also marked as planned. So the architecture is there and the UI is there, but the test suite is not, and if you adopt this as a base, adding tests is your first task rather than an inherited asset.

Running it: the Gradle wrapper, the demo APKs, and the API dependency

There is no install command in the readme, so the practical routes are the ones the project actually points at.

The repository ships a Gradle wrapper, with gradlew and gradlew.bat alongside the Gradle directory and the version catalog in gradle.properties, so the project builds with the wrapper it carries rather than a system Gradle installation. The build is driven by the Kotlin DSL build files at the top level and in build-logic/.

For seeing the app without building anything, there are two prebuilt binaries hosted on the Chinese Android distribution platform. The release build is the recommended one at about 3.6MB, described as a stable version optimised for everyday use with the best performance and size. The debug build for developers is about 19MB, it carries a .debug suffix in its package name so it can coexist with the release version, and it has LeakCanary and Chucker built in, with long pressing the launcher icon giving quick access to Leaks and Open Chucker. The readme warns that the debug version is slower and larger because debugging is on and code shrinking is off, and suggests allowing notification permission so Chucker can show live request notifications. The stated minimum is Android 6.0 and later.

The important caveat for anyone planning to build it: the app talks to a backend. The readme links API documentation hosted on Apifox, and says the documentation is kept in sync with the project progress, covering request parameters and response data samples for each endpoint. Without a reachable backend, the app will render shells of screens rather than a working shop.

A second, leaner scaffold for people who want to start smaller

One of the more thoughtful things in the readme is the second project the author maintains alongside this one.

The readme explains that many students want to build on top of CoolMallKotlin, or to start a business quickly on the same technology stack, so the author prepared a separate trimmed single module Jetpack Compose empty scaffold called AndroidProject-Compose, with detailed documentation for it.

The documentation says that scaffold keeps only the basic capabilities and sample routes, that you can pull the repository and run it and fill in business logic as needed, and that it is easier to learn from for architecture splitting and modularisation. It also says that most of the basic capabilities and documentation notes from CoolMallKotlin apply there as well, so a newcomer gets the guidance without the full feature set.

That distinction is the right one to make, and it is a good indicator of how the project is meant to be used. CoolMallKotlin is the reference implementation to read, and the scaffold is the thing to write in. A developer who clones the full project and then deletes most of it has made a messier version of the scaffold.

The documentation for the scaffold is at a separate address, and the API documentation for the mall is at another, so the two are kept apart.

Mirrors, docs and the state of the repository

The project is MIT licensed and hosted on both GitHub and Gitee, the Chinese Git hosting service, with the same repository path on each. The Gitee mirror is a practical detail for anyone outside China who finds GitHub slow, and it is the kind of thing that tells you about the project's actual user base. The homepage link in the repository metadata points at a Juejin article, the Chinese developer blogging platform, and the readme also links an English translation, README_EN.md, plus a DeepWiki badge for the repository.

On maintenance, the facts are worth stating plainly. The repository is not archived, and the last push was on 2026-04-07. The recent releases are v1.1.2 on 2026-04-07, v1.1.1 on 2026-04-04 and v1.1.0 on 2026-02-17.

So the code was being worked on up to April 2026, and the release line is still on 1.1.x with a change roughly every couple of months in that period. The readme also carries a note that preview versions update from time to time and may not fully synchronise with the latest code changes, which is an honest admission that the distributed demo build can lag the repository.

The project description frames it as a full-featured Android Compose app framework for real-world projects, and the readme explains that the author is a solo developer who put more than half a year of spare time into it, that the progress may be slower than a dedicated team, and that some features are not yet complete. That framing is consistent with the per-feature status labels, and it is the reason to read the labels before planning around any particular screen.

Editorial conclusion

CoolMallKotlin fits an Android developer who wants one complete, readable Compose project to study the MVVM and Clean Architecture split, or who wants a starting point for a second development of a small shop. It does not fit a production team looking for a maintained backend or a complete test suite, since the readme marks test coverage and large screen support as planned work. Before using it as a base, read the per-feature status list, confirm the API contract in the published interface documentation, and check that the feature modules you actually need are marked as implemented rather than page-only.

Frequently asked questions

Official sources

1. Joker-x-dev/CoolMallKotlin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases