Compose Navigation Observability Across Every KMP Target

Kotzilla SDK 2.2.0 and Console 4.5.0 bring first-class screen-level observability to Compose Navigation 2 and Navigation 3, on Android, iOS, Desktop, JS, and WASM. No manual instrumentation required.

The Observability Gap in Compose-Based Apps

For years, Android observability was built around Activities and Fragments. Monitoring tools hooked into well-defined lifecycle callbacks (onCreate, onResume, onPause) to track screen transitions, rendering performance, and user flows.

Compose Navigation changed the rules. Screens are composable functions. Navigation is driven by a NavController and typed routes. There is no Activity to intercept, no Fragment backstack to observe. For most monitoring tools, Compose screens are effectively invisible at runtime.

This gap has grown more critical as Compose Multiplatform extends screen-first navigation to iOS, Desktop (JVM), JavaScript, and WebAssembly targets. Developers shipping cross-platform apps with shared Compose navigation graphs have had no reliable way to answer basic questions:

• Which screen is slow?
• What was the user doing before the crash?
• How long did users spend on this screen before dropping off?

Kotzilla SDK 2.2.0 closes this gap.

What Is Compose Navigation Observability?

Compose Navigation observability is the ability to track, measure, and analyze screen transitions in apps built with Jetpack Compose or Compose Multiplatform, including rendering times, session sequences, and ANR events, at the same level of detail traditionally available only for Activity- and Fragment-based apps.

Kotzilla achieves this by auto-instrumenting Compose Navigation route boundaries. Every screen transition emits a SCREEN_LIFECYCLE event carrying the full route name, screen type, and timing data. No manual tracking calls. No wrappers around your NavHost.

How Kotzilla Instruments Compose Navigation

Automatic Route Boundary Detection

SDK 2.2.0 automatically instruments both Navigation 2 and Navigation 3 route boundaries. Each screen visit emits a SCREEN_LIFECYCLE event with:

• The full route name, including typed route details when available
• A screen type tag: compose_nav2 or compose_nav3
• Precise timing for the screen visit duration

Activities and Fragments retain their existing tags (activity, fragment), so mixed-navigation apps (common during Compose migrations) display all screen types in the same unified timeline.

Navigation 3 and Typed Routes

Navigation 3 is the type-safe navigation API introduced for Compose. Kotzilla SDK 2.2.0 tracks Navigation 3 screens across all KMP targets: Android, iOS, Desktop (JVM), JS, and WASM. Typed routes preserve their full class name in Kotzilla, with safe route details attached when available.

This means a shared KMP navigation graph is observable across all platforms without any platform-specific instrumentation.

Multi-Module Compose Projects

For apps using multi-module Compose Navigation, apply the Kotzilla Gradle plugin at the root build script:

// root build.gradle.kts plugins {     id("io.kotzilla.kotzilla-plugin") } 

This ensures that route code compiled in feature modules is captured. Feature modules do not need their own SDK API keys; only the app or main runtime module does. Projects using isolated project builds should apply the plugin directly in every route-owning module instead.

What You See in the Kotzilla Console

Screen Rendering Table in the Dashboard

The Dashboard's Screen Rendering table now includes Compose screens alongside Activities and Fragments. Each Compose screen is listed with:

• Rendering times
• Session count
• ANR occurrences
• Screen type tag (COMPOSE_NAV3 or COMPOSE_NAV2)

This makes it possible to directly compare rendering performance across your entire screen inventory, regardless of how each screen is implemented.

Compose Screens in the Session Timeline

In individual user sessions, the Timeline renders SCREEN_LIFECYCLE events with their own grouping, colors, and symbols, interleaved with Android activity events and Koin dependency resolutions.

You see the exact sequence of screens a user moved through, what happened on each one, and how long they spent there, giving you the same session-level context for a Compose app as you've always had for Activity-based apps.

Why This Matters for Kotlin Multiplatform Development

Kotlin Multiplatform (KMP) development increasingly relies on shared UI and navigation logic. Compose Multiplatform makes it practical to share entire screen hierarchies across Android, iOS, and web targets.

But shared code introduces shared blind spots. A rendering regression introduced in a shared composable affects every platform simultaneously. Without cross-platform screen observability, catching it requires reproducing it manually on each target.

Kotzilla SDK 2.2.0 makes SCREEN_LIFECYCLE events platform-agnostic. The same event structure, the same route names, and the same timing data surface in the Console regardless of whether the session originated on Android, iOS, Desktop, or a browser.

Build-Time Regression Detection

SDK 2.2.0 also introduces a build-time report that runs automatically during Gradle builds via auto-wired kotzillaBuildReport{Variant} tasks. The build fails by default if a FAIL status is detected, catching regressions before they ship.

To opt out of build failures without disabling the report:

kotzilla {     skipBuildReportFailure = true } 

This integrates observability into the CI/CD pipeline, not just the runtime.

Migration and Compatibility Requirements

To use Compose Navigation observability with SDK 2.2.0:

• Android apps require compileSdk 35+
• Navigation 3 Android projects require compileSdk 36+ and minSdk 23+
• KMP native and web targets require Kotlin 2.2+

Compatibility ceilings for this release include Kotlin 2.3.20, AGP 9.2.0, Gradle 9.5.0, Compose BOM 2026.04.01, AndroidX Navigation Compose 2.9.8, and Compose Multiplatform 1.10.3.

Frequently Asked Questions

Does Kotzilla support Compose Navigation without any code changes?

Yes. SDK 2.2.0 auto-instruments Compose Navigation route boundaries. No manual tracking calls or NavHost wrappers are required.

Which Compose Navigation versions are supported?

Both Navigation 2 and Navigation 3 are supported. Screen type tags distinguish them as compose_nav2 and compose_nav3 in the Console.

Does Compose Navigation observability work on iOS and Desktop?

Yes. SDK 2.2.0 tracks Compose Navigation screens across all KMP targets: Android, iOS, Desktop (JVM), JS, and WASM.

What happens in apps that mix Compose and Fragment navigation?

Compose screens (tagged compose_nav2 or compose_nav3), Activities, and Fragments all appear in the same Dashboard table and session Timeline, making mixed-navigation apps fully visible.

Is the Gradle build report opt-in?

No. The kotzillaBuildReport{Variant} task runs automatically. Build failure on a FAIL status is the default behavior. You can disable failure-on-fail via skipBuildReportFailure = true in the kotzilla {} block.

Summary

Kotzilla SDK 2.2.0 and Console 4.5.0 deliver the first complete Compose Navigation observability solution for Kotlin Multiplatform apps. Auto-instrumented route boundaries, full Navigation 3 support, and a unified Console view give teams the same screen-level visibility in Compose that they've always had in classic Android development, extended to every KMP platform in a single integration.

For setup details, see the KMP guide and CMP guide in the Kotzilla documentation.