Kide's AI-first debugging approach (FlightRecorder, interceptors, and MCP agent ports) is something none of the other current MVI libraries offer. As AI coding assistants become mandatory tools for development teams, an architecture built specifically to be understood and debugged by AI is a massive strategic advantage.

Agent-Native Debugging

Classic MVI debug tooling renders a GUI for human eyes. Kide goes further by targeting the entity that increasingly does your debugging: your AI coding agent.

Using the kide-devtools module, Kide keeps a queryable, causally ordered trace of a processor's life. An embedded MCP server exposes your running app as agent tools:

// In your debug builds:
val recorder = FlightRecorder<SearchIntent, SearchViewState, SearchSideEffect>()
val processor = SearchProcessor(useCase, interceptors = listOf(recorder))
KideDebug.attach("search", processor, recorder)
KideMcpServer.start(context) 

What can your agent do? Connect your agent (like Claude or Antigravity) to http://localhost:8765/mcp. You can now simply ask: "Why is isLoading stuck on the search screen?" Your agent will read the trace, correlate it with your source code, reproduce the bug by dispatching live intents into your emulator, and generate a Kotest replay scaffold for you automatically.

Modules

Kide is highly decoupled. Use only what you need:

Installation

Kide is published to Maven Central under the group org.fuusio.kide. The latest release is 1.1.0.

1. Add Maven Central

Make sure mavenCentral() is in your repositories (in settings.gradle.kts):

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}

2. Declare the dependencies

Add only the modules you need. In a Kotlin Multiplatform project, put the shared modules in commonMain:

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation("org.fuusio.kide:kide:1.1.0")                     // Core MVI engine
            implementation("org.fuusio.kide:kide-navigation:1.1.0")          // Navigation 3
            implementation("org.fuusio.kide:kide-clean-architecture:1.1.0")  // Clean Architecture
            implementation("org.fuusio.kide:kide-koin:1.1.0")                // Koin DI helpers
            implementation("org.fuusio.kide:kide-decompose:1.1.0")           // Decompose host
            implementation("org.fuusio.kide:kide-voyager:1.1.0")             // Voyager host
        }
        commonTest.dependencies {
            implementation("org.fuusio.kide:kide-test:1.1.0")                     // Presentation testing DSL
            implementation("org.fuusio.kide:kide-clean-architecture-test:1.1.0")  // Use-case testing DSL
        }
    }
}

For debug builds only, add the agent-native debug tooling:

// e.g. an androidMain / debug source set
implementation("org.fuusio.kide:kide-devtools:1.1.0")

For a single-platform (e.g. Android-only) project, declare them in the regular dependencies { } block instead:

dependencies {
    implementation("org.fuusio.kide:kide:1.1.0")
    testImplementation("org.fuusio.kide:kide-test:1.1.0")
}

Using the Gradle version catalog

If you use a libs.versions.toml catalog, declare a shared version and the artifacts:

[versions]
kide = "1.1.0"

[libraries]
kide = { module = "org.fuusio.kide:kide", version.ref = "kide" }
kide-navigation = { module = "org.fuusio.kide:kide-navigation", version.ref = "kide" }
kide-clean-architecture = { module = "org.fuusio.kide:kide-clean-architecture", version.ref = "kide" }
kide-koin = { module = "org.fuusio.kide:kide-koin", version.ref = "kide" }
kide-decompose = { module = "org.fuusio.kide:kide-decompose", version.ref = "kide" }
kide-voyager = { module = "org.fuusio.kide:kide-voyager", version.ref = "kide" }
kide-test = { module = "org.fuusio.kide:kide-test", version.ref = "kide" }
kide-clean-architecture-test = { module = "org.fuusio.kide:kide-clean-architecture-test", version.ref = "kide" }
kide-devtools = { module = "org.fuusio.kide:kide-devtools", version.ref = "kide" }

Then reference them from your build script:

commonMain.dependencies {
    implementation(libs.kide)
    implementation(libs.kide.navigation)
}
commonTest.dependencies {
    implementation(libs.kide.test)
}

Core concepts

Kide's presentation layer is a unidirectional data flow built around one class, PresentationProcessor<I, S, E>:

flowchart TD
    UI[Compose UI] -- dispatch(ViewIntent) --> PP[PresentationProcessor]
    PP -- map() --> Action[Action]
    
    Action -- reduce --> VS[ViewState]
    Action -- async work --> VS
    Action -- sideEffect --> SE[SideEffect]
    
    VS -- collectAsState --> UI
    SE -- collect --> UI

• A ViewIntent describes a user interaction or UI event.
• The processor maps each intent to an Action (or null for a no-op).
• Actions either reduce the ViewState (the single source of truth the UI renders), or emit one-time SideEffects (navigation, toasts, …), or run asynchronous work.

Execution guarantees

• No intent is dropped. Intents are queued and processed sequentially in dispatch order.
• Deterministic reduction order. Synchronous actions execute inline on the intent loop.
• Non-blocking use cases. An AsyncAction runs in its own coroutine; long-running work never stalls the intent loop. Executions can be coalesced with a cancellation key: dispatching an action with the same key cancels the previous, still-running one.
• No side effect is lost. Side effects are buffered until a collector attaches and are delivered exactly once — including effects emitted during configuration changes.
• Errors do not kill the processor. An exception thrown while mapping or executing is caught, logged, reported to interceptors (KideInterceptor.onError) and to the processor's overridable onError, and the loop continues with the next intent.

Advanced Capabilities

• ViewState Persistence: Opt-in, schema-safe state restoration across process death using kotlinx.serialization. No custom saver abstractions required!
• Interceptors: Hook into the MVI lifecycle for analytics, logging (KideLog), or custom monitoring.
• Clean Architecture: Scale massive apps with structured UseCaseProcessors that can emit domain-state changes directly to your processors.

Quick start

1. Define the contract

data class SearchViewState(
    val query: String = "",
    val results: List<Project> = emptyList(),
    val isLoading: Boolean = false,
) : ViewState

sealed interface SearchIntent : ViewIntent {
    data class UpdateQuery(val query: String) : SearchIntent
    data object TriggerSearch : SearchIntent
}

sealed interface SearchSideEffect : SideEffect {
    data class ShowToast(val message: String) : SearchSideEffect
}

2. Implement the processor

class SearchProcessor(
    private val searchUseCase: SearchGitHubProjectsUseCase,
) : PresentationProcessor<SearchIntent, SearchViewState, SearchSideEffect>(SearchViewState()) {

    override suspend fun map(intent: SearchIntent): Action<SearchViewState, SearchSideEffect>? =
        when (intent) {
            is SearchIntent.UpdateQuery -> reduce { copy(query = intent.query) }

            SearchIntent.TriggerSearch ->
                if (state.query.isBlank()) {
                    sideEffect { SearchSideEffect.ShowToast("Query cannot be empty") }
                } else {
                    composite(
                        reduce { copy(isLoading = true) },
                        async(cancellationKey = "search") {
                            val result = searchUseCase.execute(state.query)
                            reduce { copy(results = result.getOrDefault(emptyList()), isLoading = false) }
                        },
                    )
                }
        }
}

Action builders available in map():