Testing Compose In Release Mode

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 87cfb886f00d · 16 Oct 2026Report an issue or request a re-scan

• Publisherskydoves GitHub userOwner of the repository this skill is read from
• Source folderskydoves/compose-performance-skills/measurement/testing-compose-in-release-modeThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict87cfb886f00dA new audit runs when the source changes
• Repository statusNot archivedLast push 121 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Use this skill to ensure Jetpack Compose performance numbers reflect production reality by measuring against a release variant with R8 enabled, Live Literals disabled, and Compose Compiler reports read from the release…

---
name: testing-compose-in-release-mode
description: Use this skill to ensure Jetpack Compose performance numbers reflect production reality by measuring against a release variant with R8 enabled, Live Literals disabled, and Compose Compiler reports read from the release output directory. Covers why debug builds lie (interpreted Compose runtime, JIT warmup, Live Literals constant-getters), how to set up a release-with-symbols measurement build, and how to wire Macrobenchmark, Compose Compiler reports, Layout Inspector, simpleperf, and Android Studio Profiler against it. Cited result is roughly 75 percent startup gain and 60 percent frame-render gain debug to release. Use when the developer reports "slow startup", "jank", "dropped frames", "high recomposition count", or quotes timings from `assembleDebug`, Layout Inspector, or `CompilationMode.None`. Use when reviewing a perf bug, setting up a CI perf gate, or before filing a perf regression.
license: Apache-2.0. See LICENSE for complete terms.
metadata:
  author: Jaewoong Eum (skydoves)
  keywords:
  - jetpack-compose
  - performance
  - release-mode
  - measurement
  - macrobenchmark
  - live-literals
  - r8
  - layout-inspector
  - compose-compiler-reports
  - profiling
---

# Testing Compose in Release Mode — Debug Builds Lie About Performance

Compose ships unbundled — its UI runtime is loaded from app code, runs interpreted in debug, and the Live Literals plugin turns every constant into a getter. Debug recomposition counts, debug startup numbers, and debug compiler reports are not what users experience. This skill teaches Claude how to set up a release-with-symbols build for honest measurement before any perf claim is made.

## When to use this skill

- The developer reports a perf number ("startup is 1.4s", "this composable recomposes 50 times per scroll") that came from a debug build, Layout Inspector against debug, or `CompilationMode.None`.
- The developer is about to file a perf bug, open a regression report, or post benchmark numbers in a PR.
- A CI perf gate is being designed (Macrobenchmark, baseline-profile diff, frame-timing budget).
- The developer asks "why are my benchmark numbers so much worse than what I see on Play Store?".
- Compose Compiler reports are about to be read — they MUST come from the release output directory or every conclusion is suspect.

## When NOT to use this skill

- Feature development before perf is in scope — debug iteration speed is fine while functionality is being built.
- Behavior testing (correctness, integration, instrumentation tests for screens) — that is separate from perf testing and stays in debug.
- Build configuration of R8 itself — see `../../build/configuring-r8-for-compose/SKILL.md`.
- Generating a Baseline Profile from a benchmark run — see `../generating-baseline-profiles/SKILL.md`.
- Reading individual lines of a Compose Compiler report — see `../../stability/diagnosing-compose-stability/SKILL.md`.

## Prerequisites

- A working Android project with a Compose UI.
- A release signing config. A debug-signed release-mode build is acceptable for measurement (use a `signingConfig signingConfigs.debug` on the release type), but unsigned release builds will not install.
- Kotlin 2.0+ with the `org.jetbrains.kotlin.plugin.compose` Gradle plugin.
- A real physical device to run on. Emulator and Cuttlefish numbers are not interchangeable with on-device numbers.
- Familiarity with Macrobenchmark and Baseline Profiles helps but is not required.

## Why debug lies — the four mechanisms

Surface these to the developer when they push back on "but my numbers feel real":

1. **Interpreted Compose runtime.** Compose UI is a regular dependency, not part of the platform. In debug, much of the runtime executes interpreted with JIT warmup happening across the first seconds of the app. R8 in release performs lambda grouping, strips `sourceInformation()` calls, devirtualizes `ComposerImpl`, and constant-folds composable args.
2. **Live Literals.** The Live Literals compiler plugin (on by default in debug for Android Studio's live edit) wraps every literal — `0.dp`, `"Hello"`, `Color.Red` — in a getter. The recomposer treats these as dynamic, so reports flag composables as taking unstable params even when source code only uses constants.
3. **No R8 / no full mode.** Even if R8 were enabled in debug it would be configured weakly. Without R8 full mode, lambda allocations stay, `sourceInformation` strings remain, and the cost-per-frame budget is bigger than what release ships.
4. **Layout Inspector approximations.** Layout Inspector recomposition counts are approximate — they snapshot at intervals and miss intermediate work. Live Literals can also inflate them. Debug-only counts are diagnostic, not authoritative.

Cited measurement: roughly **75 percent startup gain** and **60 percent frame-render gain** when switching debug to release with R8. Source: Ben Trengrove, "Why should you always test Compose performance in release" (Android Developers Medium).

## Workflow

- [ ] **1. Configure R8 on the release variant.** This is the foundation; without it the rest of the workflow is moot. See `../../build/configuring-r8-for-compose/SKILL.md` for the full keep-rule story. Minimum:

```kotlin
android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro",
            )
            // Use debug signing if there is no release keystore yet — the build still installs.
            signingConfig = signingConfigs.getByName("debug")
        }
    }
}
```

- [ ] **2. Confirm Live Literals is not enabled for the measured variant.** Live Literals is no longer present in the new Compose Compiler Gradle DSL (Kotlin 2.0+) — the `featureFlags` enum exposes only `IntrinsicRemember`, `OptimizeNonSkippingGroups`, `PausableComposition`, a

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/skydoves/compose-performance-skills
git -C compose-performance-skills checkout 87cfb886f00d

Works in

1. 2026-10-16
   ✓SAFE B 89 / 100

   first audit · source 87cfb886f00d

Questions about Testing Compose In Release Mode

• github.com/skydoves/compose-performance-skills/tree/main/measure — the audited source at commit 87cfb886f00d and every finding aboveObserved · 16 Oct 2026

Spotted something wrong? Report a correction · Methodology