Store5: an offline-first data layer for Kotlin Multiplatform apps

What Store5 solves, and who it is written for

Most mobile apps end up hand-rolling the same plumbing: a network client, a database, an in-memory map, and a pile of code that decides which of the three answers a request. Store5 exists to replace that pile. The repository describes it as a library for reading and writing data that lives in network, disk, and memory, and the topics list names the intended audience directly: kotlin-multiplatform, offline-first, repository-pattern, kotlin-flow.

That framing matters. This is not a networking library and not a database. It is the layer above both, aimed at teams building Kotlin Multiplatform apps where the same data layer has to run on Android, iOS and other Kotlin targets. If you already have a repository pattern that works and you are happy with it, Store5 is a rewrite, not a patch. The payoff is that the fetch-and-observe behaviour is defined once instead of per feature.

How the network, disk and memory layers fit together

The README points readers to a Store Foundations page for the mechanics, so the repository itself does not spell out the data flow in prose. What the repository layout does show is the shape of the system. There are separate top-level modules named cache/, core/, multicast/, rx2/ and store/, which suggests the memory and disk caching concerns are packaged apart from the core abstractions, with multicast and RxJava 2 interop as optional additions.

The observable surface is Kotlin Flow, per the kotlin-flow topic. That is the part worth thinking about before adopting: a Flow-based store means the consumer subscribes to a stream and the store decides when to emit cached data, when to fetch, and when to push updates. The trade-off is that the update policy lives inside the store rather than in the calling code. Teams that want explicit control over every fetch will find that indirection uncomfortable; teams tired of writing it will not.

The presence of a dedicated cache module is a signal that disk and memory caching are first-class rather than something you bolt on. The presence of an rx2 module is a signal that the project has been around long enough to carry a legacy interop path.

Getting started with Store5 and building a first Store

The README does not contain dependency coordinates or install commands. It gives a three-step Getting Started path instead: the Quickstart to build your first Store, Store Foundations for the concepts, and a Handling CRUD guide for create, read, update and delete. That is where the project says to get it, so take any dependency declaration and version from the Quickstart page rather than guessing one here.

What the repository does show is that it is a Gradle build. The top-level entries include build.gradle.kts, settings.gradle, gradle.properties, gradle/, gradlew and gradlew.bat, so a checkout is built with the wrapper. The wrapper script itself is the only build invocation the repository layout supports naming:

./gradlew build

After the build, the first real use is defining a Store and reading from it. The Quickstart is the documented place for that construction, and the CRUD guide is where the write path is covered. The README does not merge the two, so read both before writing production code: the read path and the write path are documented separately, and the repository files do not show a combined example.

The beta release cadence is the main adoption risk

The most recent releases listed are 5.1.0-beta01 on 2026-09-08, 5.1.0-alpha11 on 2026-08-29, and 5.1.0-alpha10 on 2026-07-13. That is a pre-release line, not a stable one. The last push to the repository was on 2026-09-18, so the project is being worked on, but activity is not the same thing as API stability.

For a library that sits under every feature in your app, that distinction is the whole decision. A beta API means the abstraction you build on can shift between releases, and the CHANGELOG.md at the repository root is where you would track that. It also means your dependency policy matters: if your team pins only stable versions, Store5 in its current release line does not fit, regardless of how good the abstraction is.

The second limitation is documentation placement. The README is short and delegates the substance to an external site. That is a reasonable choice for a project with a foundation behind it, but it means the repository alone is not enough to evaluate Store5. If the docs site is unavailable or lags the code, you are reading source. Check that the documented version matches the artifact you intend to use before you plan around it.

Where Store5 is the wrong tool

Store5 assumes you have more than one data source worth coordinating. If your app reads from a single REST endpoint and never persists anything, the network, disk and memory distinction has nothing to coordinate, and a plain HTTP client plus a coroutine is less machinery.

It is also a poor fit if you are not on Kotlin Multiplatform. The topics name kotlin-multiplatform-mobile and kotlin-native explicitly, and the modules are structured around shared code. An Android-only app can use it, but it would be paying the multiplatform abstraction cost without the multiplatform benefit.

Finally, if your team has already settled on a repository pattern with its own caching semantics and tests, Store5 replaces that contract. The migration is not incremental: the Flow-based observation model changes how callers consume data, so the blast radius reaches every screen that reads from the repository.

Store5 compared with assembling Room or SQLDelight plus a network client

The realistic alternative is not another library of the same kind. It is assembling the layer yourself: a persistence library such as SQLDelight or Room for disk, Ktor or another HTTP client for network, and your own code to decide which one answers.

That approach gives you total control and no third-party API surface. It also means you write and maintain the cache-invalidation rules, the fetch policy, and the Flow plumbing yourself, and you write them again for each feature that needs slightly different behaviour. Store5's pitch is that this logic is the library's job, defined once, with disk and memory caching handled in dedicated modules.

The honest difference is ownership. With your own layer, the bugs are yours and the design is yours. With Store5, you inherit a pre-release API and a documentation site you do not control, in exchange for not rebuilding the same coordination logic. Which side of that trade you want depends on how many features in your app need cached, observable data.

Maintenance, licensing and upgrade cost

Store5 is licensed under Apache-2.0, with the README carrying the Mobile Native Foundation copyright notice for 2024. Apache-2.0 is a permissive licence that permits commercial use and modification, and it includes an explicit patent grant. It also requires that you preserve the licence and notice files when you redistribute. That is the general shape of the licence, not legal advice; check it against your own distribution model.

The project is not archived, and the last push was on 2026-09-18, so the codebase is being touched. The upgrade cost is concentrated in the pre-release line: because 5.1.0 is still at beta01, expect to read CHANGELOG.md between upgrades rather than assuming compatibility. Renovate is configured in the repository (renovate.json), which tells you the maintainers automate dependency updates for themselves, not that your upgrades will be automatic.

Governance is worth noting too. The project is backed by the Mobile Native Foundation and the Kotlin Foundation, per the README, and support runs through the #store channel on the official Kotlin Slack. That is a real support path, but it is community support, not a commercial SLA.

Editorial conclusion

Store5 fits Kotlin Multiplatform teams that need one fetch-and-observe abstraction over network, disk and memory, and who can track a beta API. Teams on stable-only dependency policies should not adopt it yet: the newest release listed is 5.1.0-beta01 from 2026-09-08. Before committing, read the Quickstart at store.mobilenativefoundation.org, confirm which artifacts you need from the cache/, core/, multicast/, rx2/ and store/ modules, and check whether the CRUD guide covers the write paths your app uses.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. MobileNativeFoundation/Store on GitHub
3. Project website
4. README
5. Releases