What's new
New updates and improvements to Kotzilla Platform
September 3rd, 2026
This update brings a new Jira integration (Console 4.14.1), plus updates to the MCP Server (1.15.1) and the SDK (2.3.5):
- Turn a detected issue into a Jira ticket, with the context already in it (Console): the ticket carries the root cause, the impacted sessions, the exact app and version, a link back to the Kotzilla issue, and a ready-to-run MCP prompt.
- Follow the ticket without leaving Kotzilla: the issue shows the live Jira status and assignee. The Console mirrors the ticket, Jira stays the source of truth.
- Verify a fix before you close it (MCP Server): after applying a fix, your assistant rebuilds, runs, and confirms it against a fresh session, structurally and on timing, for performance issues and now crashes.
- More accurate timings and safer crash delivery (SDK 2.3.5): background time no longer inflates screen render or startup measurements, and a detected crash is always sent right away.
Kotzilla Console 4.14.1
Kotzilla now connects to Jira, so a critical issue you find in the Console becomes an actionable ticket in the tool your team already works in. Detection stays in Kotzilla, the ticket lives in Jira, and the fix happens in your editor, with the same context flowing through all three.
A ticket that already carries the context
When you create a Jira ticket from an issue, Kotzilla pre-fills it from what it captured. The ticket body contains the diagnosis and root cause, the dependency graph with resolution timings, the impacted sessions, and the exact app and version. It includes a direct link back to the Kotzilla issue, and a ready-to-run prompt for the Kotzilla MCP Server (get_issue_context and get_fix_guidance), so whoever picks up the ticket, or their AI assistant, goes straight to the fix with the real runtime context. One ticket per issue.


Follow the ticket from the issue
Once linked, the issue shows the ticket key as a deep link, its live status, and its assignee. The status and assignee are mirrored read-only: the Console follows the ticket lifecycle, it does not manage tickets, and Jira remains the source of truth. You can also link an existing ticket to an issue, or unlink one. Unlinking only removes the link inside Kotzilla, it never deletes the ticket in Jira.

Connect Jira for your organization
An organization admin connects Jira once from Org Settings, using OAuth, and picks a default project. Each app can override that project from its own settings. See Jira ticket integration for the full setup.
Kotzilla MCP Server 1.15.1
Verify a fix before you close it
After your assistant applies a fix, it confirms the fix actually worked. It rebuilds, runs the app, and checks that a fresh session arrived, then verifies the fix two ways:
- structurally, that the anti-pattern is gone (the component is off the main thread, out of the startup graph, lazy, created once);
- on timing, comparing the new version against the same issue in the same local environment, not against generic production thresholds.
Crashes are covered too: the assistant reproduces the crash first, then confirms the exact path that crashed now runs clean.
You do not need to ask for the check, it runs as part of the fix:
Fix the ANR in my app Now In Android

Kotzilla SDK 2.3.5
SDK 2.3.4 and 2.3.5 sharpen measurement accuracy and crash delivery.
- Accurate screen render time. A screen sent to the background mid-navigation no longer reports the backgrounded time as slow render or ANR time (Android for now).
- Honest startup timing. A process woken in the background (push, job, broadcast) that later opens its first screen is now reported as a warm start, instead of counting the whole idle wait as cold startup.
- Crashes are never held back. A crash detected while the SDK's connection is temporarily blocked is now sent right away, instead of being held locally for up to the block duration.
See the full list in the SDK changelog.
August 5th, 2026
This update brings new capabilities across the Kotzilla Platform, including the Console (4.13.0), the Koin IDE Plugin (1.6.0), the MCP Server (1.12.1), and the SDK (2.3.3):
- Connect your AI assistant to Kotzilla from the IDE (Koin IDE Plugin): one dialog wires your AI coding assistants to the Kotzilla MCP, so they can analyze your app's real production issues, trace root causes, and apply guided fixes without leaving your editor.
- Works with more than Koin: Kotzilla now monitors apps built with Hilt, Metro, Dagger, or manual DI too, with setup guided by the MCP Server.
- App-wide performance and stability analysis (Console): a new All Versions view analyzes the whole app, flags what needs attention, and shows how your latest release is performing.
- A more robust SDK (2.3.3): build and multiplatform fixes since 2.3.0, including reliable root-level plugin apply and iOS/Compose linking.
Kotzilla Console 4.13.0
An All Versions view of your app's health
The Dashboard now offers an All Versions view: a single analysis of the whole app that surfaces what needs attention, next to how your latest deployed version is performing. Teams get a clear read on the app overall and on the new release at once, without switching versions. It shows version distribution, an Application Health summary across all versions, and the last version detected, each linking into the issues behind the numbers.

Selecting a specific version keeps the familiar per-version view (Health & Stability, App startup, Critical Issue Trends, and Screen Rendering).
Now monitoring apps built with Hilt, Metro, or manual DI
Kotzilla now monitors apps built with Hilt, Metro, or manual DI, not just Koin. Here are Google's Now in Android (Hilt) and JetBrains' KotlinConf app (Metro) running in the Console. See Setup with Hilt, Metro, or manual DI for what is supported today.


Koin IDE Plugin 1.6.0
Plugin 1.6.0 brings one-dialog MCP setup for AI coding assistants, plus faster indexing and more accurate Koin understanding.
Connect AI assistants to Kotzilla MCP from the IDE
From a single Connect dialog in Android Studio or IntelliJ IDEA, wire your AI coding assistants to the Kotzilla MCP Server. They get the full context Kotzilla captures, your app's dependency structure and its real production behavior, so they can analyze issues, find root causes, and apply guided fixes in your code.
- Covers 11 assistants today, including Claude Code, OpenAI Codex, Gemini CLI, Cursor, Windsurf, GitHub Copilot, Junie, and JetBrains AI Assistant.
- Shows each assistant only when it is detected in your environment.
- Choose exactly which to connect with per-assistant checkboxes.
- See which are already connected, and disconnect them (or get exact manual cleanup steps) from the same place.
The Koin Configuration tool window suggests connecting when nothing is set up yet:

The Connect dialog lists the assistants detected in your environment, each with its own checkbox and scope:

Once connected, your assistant can call the Kotzilla MCP tools directly. Here GitHub Copilot runs a report inside the IDE:

Faster, more accurate Koin understanding
Koin indexing is faster and steadier, with near-instant updates after small edits and fewer full graph rebuilds. DSL and Annotations parsing is more accurate, covering scoped definitions, dynamic parameters, fully qualified and receiver-style calls, typed constructor declarations, and @KoinWorker. Android ViewModel navigation, searchable app selection, mutable list bindings, and multi-project switching are all smoother.
Kotzilla MCP Server 1.12.1
The MCP Server can now set up the SDK in projects that do not use Koin. Ask your AI assistant to set up Kotzilla, and it detects your dependency injection setup and configures the SDK accordingly, whether the app uses Koin, Hilt, Dagger, Metro, or manual DI, including the build wiring that KSP projects (Hilt, Room) need.
For example, in a Hilt or Metro app:
Register my app on Kotzilla and set up the SDK
The assistant detects there is no Koin, adds the Gradle plugin and kotzilla.json, and wires the right startup for each target. See Setup with Hilt, Metro, or manual DI.
Kotzilla SDK 2.3.3
SDK 2.3.3 rolls up build and multiplatform fixes since 2.3.0.
- Reliable root-level plugin apply. Applying the plugin at the root no longer breaks multi-module KMP builds: the
KotzillaScreenHost has none or several referencescompile error and the Xcode dSYM setup race are fixed, so root-level apply is safe again. - KMP iOS with Compose. Fixed a capability conflict that could fail iOS framework linking when both
kotzilla-sdkandkotzilla-sdk-composewere present, and corrected the iOS early-start module export that followed from it. - Android backup and manifest. Fixed the 2.3.0 manifest-merger conflict for apps that declare their own backup rules. SDK state now lives in
noBackupFilesDir, excluded from Android backup by construction, so you can remove anytools:replaceworkaround. - Compose route and startup fixes. A route content lambda with an early return no longer breaks R8/D8 minified builds, and a Koin-logger self-reference that could crash the app on startup is fixed.
- Build report and Gradle robustness. The build report now covers all versions of the app, the build-id task no longer conflicts with source-generating tasks, and a missing Kotlin source set warns instead of failing Gradle sync.
See the full list in the SDK changelog.
Issue detection and thresholds
We tuned detection to cut noise and keep the focus on what impacts users, and aligned thresholds with Google Play targets.
Fewer, higher-signal issues. Detection now centers on the issues that impact users: crashes, ANRs, slow screens, slow transitions, cold and warm startup, and main-thread and background-thread performance.
Three dependency issue types are retired, since they generated a lot of noise:
- Dependency Performance
- Child Dependency Performance
- Dependency Complexity
The cases that actually block users still surface: a dependency resolution over 100 ms on the main thread is still detected as a Main Thread Performance issue. Sessions analyzed before this change still show the retired types; new sessions do not. See Retired issue types.
Detected issues and their thresholds. These are the issue types detected today and the threshold at which each is raised:
| Issue | Detection threshold |
|---|---|
| Slow screen | 500 ms |
| Slow transition | 500 ms |
| Cold startup | 3500 ms |
| Warm startup | 1500 ms |
| ANR | 4500 ms |
| Background thread | 200 ms |
| Main thread | 100 ms |
July 7th, 2026
This update brings new capabilities across the Kotzilla Platform, including the SDK (2.3.0), the Console (4.12.0), and the MCP Server (1.11.1):
- Privacy-first data collection: gate the entire SDK behind explicit user consent, off by default so nothing changes unless you opt in.
- Automatic startup capture: the SDK now boots at process start, so crashes and startup timing are caught from the earliest possible moment.
- See who is impacted, down to the session (MCP Server): your AI assistant breaks affected sessions down by device and OS and points you to the worst session behind an issue.
- Monitor what matters, per version: turn data collection on or off per app version, from the Console or your AI assistant, to cut noise and cost.
- Guided fixes from Issue Details (Console): each issue hands off to the Kotzilla MCP Server for a guided fix in your editor.
Kotzilla SDK 2.3.0
SDK 2.3.0 focuses on privacy, automatic startup, and startup performance.
Universal consent gate
Apps that must obtain user opt‑in before collecting any data can now gate the entire SDK behind explicit consent. Turn it on with kotzilla { consentRequired = true }, then record the user's decision:
KotzillaSDK.setConsent(KotzillaConsent.GRANTED) // or NOT_GRANTED
Until a decision is recorded, the SDK buffers telemetry locally and sends nothing. On grant, the buffer is replayed; on refusal (or forgetMe()), it is wiped along with in‑flight uploads and native crash files. The gate is off by default, so upgrading from 2.2.x changes nothing. See Privacy & user consent.
Automatic start (early start)
The SDK now boots automatically at process start (before Application.onCreate on Android, before main() on iOS, and on first SDK reference on the JVM), so crashes and startup timing are captured from the earliest possible moment, even before your monitoring() call. It is on by default and can be disabled globally or per platform. See Automatic start (early start).
Startup performance
Every launch now produces an automatic cold/warm startup metric (duration + launch source; Android for now), and a new mark(label, track) API lets you time your own startup phases. See Startup tracing.
Latest ecosystem support
Verified against Kotlin 2.4.x, AGP 9.2.1, Gradle 9.6.0, Jetpack Compose BOM 2026.06.00, and Compose Multiplatform 1.11.1.
Bump the version and rebuild:
id("io.kotzilla.kotzilla-plugin") version "2.3.0" apply true
See the full list in the SDK changelog.
Kotzilla Console 4.12.0
The Console side of this release reworks issue details around metrics and a guided MCP resolution flow, and adds per-version monitoring controls.
Reworked Issue Details
Issue Details now leads with the metrics that matter for each issue and a resolution flow that hands off to the Kotzilla MCP Server, so you go from an issue to a guided fix in your editor. Performance status is now handled consistently across screens and issues.

Per-version monitoring toggles
Application Settings now lets you enable or disable monitoring per app version. Controls are read-only when you do not have permission to change them, and an inactive app shows a clear paused banner. The same per-version control is available directly from the Kotzilla MCP Server.

Timeline session summary and smaller improvements
The Timeline session summary now carries more metadata fields and SDK properties, adds an event thread display, and improves duration and scope ID formatting.

Kotzilla MCP Server 1.11.1
The MCP Server adds impacted-population analysis and per-version data gating, so your AI assistant can tell you who is affected by an issue and control what the platform ingests.
See who is impacted, down to the session
When you ask about an issue, the assistant can now give you the exact population behind it: which devices, which OS versions, and how many production sessions each one hit. get_issue_context returns that breakdown plus a list of impacted sessions sorted by worst or most recent, and you can filter issues, screens, and issue context by device or OS. From there you drill straight into the worst session's timeline.

Per-version data gating
list_app_versions returns each app version with whether the SDK is ingesting data for it and whether it has a mapping file. set_app_versions_enabled turns ingestion on or off per version. This is the same per-version monitoring toggle available in the Console, usable directly from your AI assistant.
See the Kotzilla MCP Server page for the full reference.
June 18th, 2026
This update ships the SDK (2.2.3), a recommended upgrade that corrects how Koin events are ordered in the session timeline.
Kotzilla SDK 2.2.3
Correct timeline ordering of Koin events
Koin events — DI resolutions, module load, eager instances, scope create/drop — now keep their true chronological position in the session timeline, relative to Activity, Fragment, and Compose screen events.
Previously, dependency work performed very early in the app lifecycle could appear after the first screen event even though it happened before it. The most visible case was the startKoin / module-load / eager-singleton resolutions that run during Application.onCreate: they would show up later in the timeline than the first Activity event, because Koin events were numbered when the SDK drained its internal buffer rather than at the moment they occurred. Activity, Fragment, and Compose events were already stamped at the moment they happened, so the two could disagree.
In 2.2.3, every event is sequenced at the instant it occurs. The timeline now matches wall-clock order across the Koin ↔ screen boundary, so screen-rendering and startup analysis attribute the right work to the right phase (for example, the Application.onCreate DI cost is no longer mixed into an Activity's create→resume window).
This is a recommended upgrade for any app that relies on timeline ordering or screen-rendering metrics. There are no API or configuration changes — bump the version and rebuild:
id("io.kotzilla.kotzilla-plugin") version "2.2.4" apply true
See the full list in the SDK changelog.
June 16th, 2026
This update brings new capabilities across the Kotzilla Platform, including the Console (4.7.0) and the SDK (2.2.2):
- ANRs and slow screens are now Critical issues: detected automatically and shown in the Issues View, with the Dashboard ANR-free rate linking straight to them.
- Reliable deobfuscation across builds: a single app version can now hold several mapping files, so component names, dependencies, and crash stack traces always resolve to the exact mapping of the build that produced them.
- More accurate Compose render timing: Compose screens now measure render time and time to interactive directly on-device.
- Faster onboarding: a new MCP-guided setup flow in the Console, plus refreshed setup instructions for SDK libraries.
- Monitoring you can trust in production: the SDK absorbs its own errors and handles network drops quietly, so it never crashes or slows your app, and it keeps collecting data through bad networks.
Kotzilla Console 4.7.0
The Console side of this release makes ANRs and slow screens first-class critical issues, brings end-to-end mapping file management, adds a faster MCP-guided onboarding, and refreshes the UI.
ANRs and slow screens as Critical issues
ANRs and slow-rendering screens now appear in the Issues View, across both the Critical Issues and All Issues tabs, alongside every existing issue type (startup, main and background thread performance, dependency performance, crashes, and more). One prioritized place to see what is hurting your users the most.

Drill into ANRs from the Dashboard
The ANR-free rate on the Dashboard is now clickable. Selecting it takes you straight to the Critical Issues view filtered by ANRs, so you can go from a health number to the actual ANRs behind it in one click and analyze them as a first-class issue.

End-to-end mapping file management
Rebuilding the same version name used to overwrite the previous mapping file, leaving component and dependency names only partially deobfuscated. A single version can now keep several mapping files, so every signal, from component and dependency names to crash stack traces, resolves to the exact mapping of the build that produced it, thanks to the per-build Build ID generated by the SDK (see below). You can still upload mapping files manually, and now download any of them by ID directly from the Console.

See Mapping files for production builds for the full workflow.
MCP-guided onboarding
Setting up a new app now starts with a setup choice screen. You can pick the recommended MCP-guided flow, where one prompt to your AI assistant registers the app and applies all the SDK changes for you, or choose manual setup, which still walks you through the existing step-by-step instructions for your project type.

Clearer onboarding for SDK libraries
If you are monitoring an SDK library rather than an app, the Console onboarding now shows how to start Kotzilla from your library's isolated Koin context. Use koinApplication { ... } (not startKoin { ... }) so your SDK's context stays separate from the host app's, and call monitoring() last, after your modules(...) and includes(...). The plugin supplies the key from kotzilla.json, so there is nothing to wire by hand.

See the SDK setup for SDK libraries guide for the full flow.
Refreshed UI and smaller improvements
This release refreshes the UI: icons migrate to Lucide with harmonized design tokens and sizing, toast notifications are added, and the application settings UI is improved. A few more refinements:
- Tables are more readable, with a fixed layout, optional column resizing, responsive widths, and a middle ellipsis that keeps the meaningful last segment of long dotted names (for example
com.go…MainActivityViewModel), with full names on hover. - The Screen Rendering table now uses a clickable screen name in place of the Analysis icon, the invite-user form no longer keeps stale state, duration filtering was removed from impacted sessions, and the ambiguous quota alert was deactivated.
Kotzilla SDK 2.2.2
SDK 2.2.2 (and 2.2.1) sharpen screen-performance data for Compose apps, make crashes always resolve to the right mapping file, and harden the SDK so it never interferes with your app.
More accurate Compose screen render timing
Kotzilla now measures how long your Compose screens take to render directly on-device, using a monotonic clock from the moment a screen is created. The timing is no longer inferred from server-side timestamps, which were sensitive to clock skew, batching, and event ordering. Each screen reports two numbers:
- Render time: from screen creation to the first frame painted on screen.
- Time to interactive: from creation to fully resumed, which also includes the navigation transition.
In a session, the Compose lifecycle states carry these timings: the Visible state reports the render time, and the Resumed state reports the time to interactive.

This works identically for Navigation 2 and Navigation 3, and adds no new fields to the event payload (the timings ride the existing timeInMs field on SCREEN_LIFECYCLE events). While developing, enable debug logs to see a per-screen breakdown:
[Kotzilla] Screen '<name>' load funnel — CREATED/STARTED/VISIBLE/RESUMED at +<n>ms
Crashes always resolve to the exact mapping
The plugin now generates a per-build Build ID and tags every session and mapping upload with it, so crashes resolve to the exact mapping that produced them even when several builds share the same version name. On Android this is per-variant, so a release build and a minified staging build no longer overwrite each other's mappings. Each session also reports whether the build was minified, so the Console can tell a genuinely missing mapping from a build that was never obfuscated.