FlowMVI: a plug-in architecture framework for Kotlin Multiplatform

FlowMVI is a plug-in system wrapped around an MVI store

FlowMVI is described as a Kotlin Multiplatform architectural framework, and the one thing to understand about it is that its centre of gravity is the plug-in system, not the MVI pattern.

The stated idea is that the library "adds a plug-in system to your code" that helps prevent crashes, handle errors, split responsibilities, reuse code, collect analytics, debug and log operations, monitor and improve performance, achieve thread-safety, save state, and manage background jobs. That is a long list, and it is the shape of a framework aimed at teams with several features and several developers, not at a single screen.

The framing is deliberate. The project argues that architecture frameworks usually mean boilerplate, restrictions and support difficulty for marginal benefits of clean code, and says instead that it does not dictate what your code should do or look like, but focuses on building a supporting infrastructure. You can write simple, familiar MVVM+ code, or follow MVI or Redux, with no limits or requirements stated.

Underneath, the model is a store plus a set of plugins. The repository layout is divided into `core/`, `compose/`, `savedstate/`, `metrics/`, `essenty/`, `debugger/`, `test/`, `android/`, `sample/` and `benchmarks/`, so the framework is delivered as a set of modules you pick from rather than one artifact.

The intended user is a Kotlin developer shipping an app across Android, iOS, desktop and web who wants business logic to be written once and shared, and who is willing to accept a framework's opinion about how state is represented.

Writing auth, logging and analytics once, then reusing them

The core promise of the plug-in system is reuse. The documentation puts it plainly: write your auth, error handling, analytics, logging, configuration and any other code once and forget about it, focusing on more important things instead.

The mechanism for that reuse is interception. Plugins can intercept any operations, and the framework can automatically debounce, retry, batch, throttle and conflate them. In other words, instead of wrapping a call in a try/catch in every ViewModel, or writing a retry loop in every repository, you express the behaviour once as a plugin and every operation in the app inherits it.

The same idea covers side effects. The documentation lists sharing, distributing, disabling, intercepting and safely managing side effects as capabilities, which is the vocabulary of a system that treats an effect as something the framework can route rather than something each screen owns.

Two structural choices support this. There are no base classes, complicated abstractions or factories of factories, and the documentation says you write simple, declarative logic using a DSL. And business logic components are restartable and reusable, with no external dependencies and no dedicated lifecycles, which is what makes them shareable between screens and across platforms.

The core library has no dependencies beyond coroutines, and the repository lists a `stability_definitions.txt` and a `detekt.yml`, so the project is paying attention to API stability rules and static analysis rather than only shipping features.

Error recovery and logging are handled by the framework, not by you

The framework claims it can automatically recover from exceptions, prevent crashes, and report them to analytics. It also collects and views logs automatically, with the documentation suggesting you can forget about sprinkling `Log.e("asdf")` around the code.

Taken together these are the parts of a framework that change day-to-day work most. Crash reporting in an application usually means a global handler that catches, logs and forwards, and that handler is a piece of infrastructure everyone has to remember to route through. If the framework owns the interception point, the behaviour is consistent across features by construction.

The honest caveat is that the README is a feature list, not a specification of the error semantics. It does not say what happens to state after a recovered exception, whether a retry is bounded, or what a plugin is allowed to swallow. If you adopt this, the first thing worth reading in `docs/` is how the recovery and retry behaviour interacts with your own reducers, because that is where an opinionated framework can surprise you.

The same caveat applies to the claim about minimal overhead, which the documentation states as equal to using a simple Channel, with regular benchmarking. The repository does have a `benchmarks/` directory, so the claim is at least backed by something you can run, but the README does not publish figures.

Metrics, saved state and background jobs as separate modules

The catalog of published modules is the clearest description of the framework's scope, and it is published as version catalog entries:

[dependencies]
# Core KMP module
flowmvi-core = { module = "pro.respawn.flowmvi:core", version.ref = "flowmvi" }
# Test DSL
flowmvi-test = { module = "pro.respawn.flowmvi:test", version.ref = "flowmvi" }
# Compose multiplatform
flowmvi-compose = { module = "pro.respawn.flowmvi:compose", version.ref = "flowmvi" }

The Gradle DSL form covers more modules, including the Android integration and the remote debugging client:

    // Core KMP module
    commonMainImplementation("pro.respawn.flowmvi:core:$flowmvi")
    // compose multiplatform
    commonMainImplementation("pro.respawn.flowmvi:compose:$flowmvi")
    // saving and restoring state
    commonMainImplementation("pro.respawn.flowmvi:savedstate:$flowmvi")
    // metrics collection & export
    commonMainImplementation("pro.respawn.flowmvi:metrics:$flowmvi")

Three of these deserve a note. The `metrics` module is the one that collects 50+ performance metrics with Prometheus, Grafana and OpenTelemetry export. The `savedstate` module handles compressing, persisting and restoring state automatically on any platform, which is the piece that makes a shared store survive process death on Android and a rotation on desktop. The `debugger-plugin` module is a remote debugging client.

The separate `test` module matters too: the framework ships a test DSL for exercising business logic declaratively, and the documentation states the core is covered by 350+ tests.

The module split also tells you where the cost is. Every extra module is another dependency to version, another artifact to keep compatible with your Kotlin and Compose versions, and the debugger plugin is an `androidDebugImplementation`, so it never ships in a release build.

One store per target, with Compose Multiplatform as the default view layer

The platform story is broad. The README badges list Android, JVM, JavaScript, Node.js, Linux, Windows, iOS, macOS, watchOS, tvOS and WASM, and the repository topics carry the same range with compose-multiplatform, kmp, wasm and multiplatform named explicitly.

The UI story is Compose Multiplatform. The documentation calls it first class, one-liner support with Previews and UI tests, and there is a `compose/` module in the tree. That matters for a shared codebase, because Compose Multiplatform is what lets one view layer serve Android, desktop and iOS rather than forcing a platform-specific UI module into the architecture.

Around the core, the framework integrates with Decompose, Koin, Kodein, androidx.navigation and Nav3, and there is a dedicated `essenty/` module pair for the Decompose integration. The list is a compatibility claim rather than a deep one, but it removes the objection that adopting this means abandoning the DI container or navigation library you already use.

On state, the framework claims compile-time safe state machines with a readable DSL, so that you can forget about casts, inconsistent states and nulls, and it supports a UDF style, which the repository topics list as udf alongside mvi and mvvm-architecture.

The platform breadth is also the framework's main constraint. Supporting watchOS, tvOS and WASM means the common code cannot assume a platform, and it means the framework's own release cadence has to keep up with a wide matrix of targets. The documentation does not describe per-target feature differences, so that is worth checking before you commit to a target.

A dedicated IDE plugin and a desktop debugging app

FlowMVI ships tooling that most architecture libraries do not: a dedicated IDE plugin for debugging and code generation, and a desktop app for Windows, Linux and macOS. The `debugger/` directory in the repository holds the client side, and the `debugger-plugin` module is the remote debugging client that the Android debug build pulls in.

Remote debugging of a running app is a real pain point in mobile development, and the fact that this is a first-class part of the framework rather than a community tool is a genuine differentiator. The cost is a dependency on the maintainers' own tooling, and on the plugin continuing to match your IDE version.

The repository also carries a `scripts/` directory, a `skills/` directory, `AGENTS.md` and `CLAUDE.md`, plus a `.claude-plugin/` directory, which points to a documentation and agent-assistance setup alongside the code. There is a `SECURITY.md`, a `certificates/` directory and a `docs/` tree that the README points to for the fuller documentation, plus a browser-playable sample app hosted at opensource.respawn.pro/FlowMVI/sample/.

For an evaluation, that sample is the cheapest entry point: it is a running demo of the framework in a browser, so you can see the state model and the debug tooling without wiring up a project first.

Apache-2.0, but the recent tags are alpha builds

The licence field on the repository says Apache-2.0, which is permissive and appropriate for a framework you intend to build a product on. The `LICENSE.txt` file sits at the repository root.

The release channel is the thing to look at carefully. The listed releases are 3.2.1 from 2025-11-06, then 3.3.0-alpha02 from 2025-12-14 and 3.3.0-alpha03 from 2026-01-04. In other words, the most recent tagged artifacts are alpha builds of the next minor version, and the stable line to depend on is the 3.2.1 release from late 2025.

The repository is not archived and the last push was on 2026-05-31, so work has continued since that alpha, but the gap between the last push and the newest tag means the default branch carries changes that are not in a published artifact. Version your dependency deliberately: if you want the alpha, take 3.3.0-alpha03 and expect API movement, and if you want stability, pin 3.2.1.

The CI badge in the README points at a `ci.yml` workflow, and the stated test coverage is 350+ tests with regular benchmarking in the `benchmarks/` directory, which is what you would want to see from a framework that asks you to build core product logic on top of it.

Editorial conclusion

FlowMVI fits a Kotlin team that already targets several platforms through Kotlin Multiplatform and wants one place to host shared business logic, error recovery, metrics and remote debugging, and the plug-in model is the part that earns its keep once a project has more than one feature. It is a poor fit for a single-platform Android app that only needs a ViewModel, and for teams unwilling to accept an architecture framework that decides how state is represented. Before adopting, read the quickstart at opensource.respawn.pro/FlowMVI, pick the module set you actually need from the catalog rather than the whole list, and check the release channel you depend on, because the newest tagged versions are 3.3.0 alpha builds and the last push was on 2026-05-31.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. respawn-llc/FlowMVI on GitHub