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.
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:
Kotzilla SDK 2.2.0 closes this gap.
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.
SDK 2.2.0 automatically instruments both Navigation 2 and Navigation 3 route boundaries. Each screen visit emits a SCREEN_LIFECYCLE event with:
compose_nav2 or compose_nav3Activities 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 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.
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.
The Dashboard's Screen Rendering table now includes Compose screens alongside Activities and Fragments. Each Compose screen is listed with:
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.
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.
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.
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.
To use Compose Navigation observability with SDK 2.2.0:
compileSdk 35+compileSdk 36+ and minSdk 23+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.
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.
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.