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.