GM Friends. This is JetpackCompose.app’s Dispatch, sliding into your inbox like a perfectly scoped LaunchedEffect that fires exactly once and never causes trouble

This is Issue # 26 so let’s get our reading glasses out and dive right in.

 🤿 Deep Dive

Okay, real talk. How many times have you used an AI assistant for Android development and gotten back code that was technically Kotlin but spiritually wrong? Like, it compiles, but it's using deprecated APIs, ignoring lifecycle, or treating Compose like it's just a fancy XML replacement? 😤

Google just shipped something that directly addresses this: Android Bench — an official leaderboard that measures how well LLMs actually perform on real Android development tasks.

And I mean real. Not "write a function that reverses a string." We're talking:

• Resolving breaking changes across Android releases

• Domain-specific tasks like networking on Wearables

• Migrating code to the latest version of Jetpack Compose

• Navigating complex codebases and understanding dependencies

The methodology is simple: give an LLM a task sourced from public GitHub Android repos, let it attempt a fix, then verify the result using unit or instrumentation tests. No vibes. Just pass/fail. 🧪

The results? Models successfully completed between 16% and 72% of tasks. That's a wide spread, which tells you something important: not all LLMs are created equal when it comes to Android-specific knowledge. The top performer for this first release is Gemini 3.1 Pro, followed closely by Claude Opus 4.6.

The 16-72% range also tells you something practical: when you're using AI for Android tasks today, the model you choose matters a lot. Not all assistants have the same depth of Android knowledge, and now there's data to back that up instead of just gut feel.

Here’s an intentionally small Maestro flow:

appId: com.example.myapp
---
- launchApp
- tapOn:
    text: "Login"
- inputText: "[email protected]"
- inputText: "superSecretPassword123"
- tapOn:
    text: "Continue"
- assertVisible: "Welcome, Alice"

Looks fine, right? It launches the app, taps Login, types email/password, continues, asserts the welcome.

Now the question: what’s the subtle bug that makes this flow flaky or even totally meaningless across UI changes?

You will find the answer in a section below ⬇️

😆 Dev Delight

🌶️ Spicy hot-takes

Jake Wharton Wants You to Break Up with the Compose BOM

Jake Wharton dropped a blog post last December and I think it deserves more attention than it got: Let's Defuse the Compose BOM.

The TL;DR is spicy: the Compose BOM might be solving problems you don't actually have, while introducing new ones you didn't sign up for. 💣

Here's the thing most people don't realize: every AndroidX library already bundles peer dependency constraints into its Gradle module metadata. This means if a transitive dependency bumps foundation-layout to 1.10.0, Gradle automatically aligns all other androidx.compose.foundation artifacts to 1.10.0 too. No BOM required. You can literally see this in the module metadata:

"dependencyConstraints": [
  {
    "group": "androidx.compose.foundation",
    "module": "foundation",
    "version": {
      "requires": "1.10.0"
    },
    "reason": "foundation-layout is in atomic group androidx.compose.foundation"
  }
]

Gradle handles this for you. The BOM's version-alignment superpower? Already built in.

So what does the BOM actually cost you?

• It releases on an inconsistent schedule — sometimes monthly, sometimes skipping months entirely, sometimes releasing with zero actual changes

• It masks the real library versions behind a date-based string like 2025.10.01. When someone says "that bug was fixed in Foundation 1.9.4," you now have to go look up a mapping table to figure out if your BOM version includes it

• If you're doing gradual AndroidX beta adoption (and you should be), you're already partially overriding the BOM anyway — so it's not even the full source of truth

Jake's recommendation: for new projects, just define the two or three Compose library group versions you actually use directly in your version catalog, the same way you handle every other dependency. For existing projects, consider whether the BOM is earning its keep.

🥂 Tipsy Tip

Compose Shared Element Debugging Just Got a Lot Less Painful

If you've ever tried to debug a shared element transition in Compose and ended up staring at your screen like 🧍 wondering why your hero animation is doing something deeply cursed — good news. The Compose team heard you.

In Compose 1.11.0-alpha03, a new composable called LookaheadAnimationVisualDebugging was quietly added, and it's exactly what it sounds like: a debug wrapper that adds visual cues to your shared element transitions so you can actually see what's happening under the hood.

The usage is beautifully simple. When you're debugging, just wrap your SharedTransitionLayout in it:

LookaheadAnimationVisualDebugging {
    SharedTransitionLayout {
        // your shared element transition content
    }
}

This is an alpha API, so treat it as a debugging tool only — don't ship it to production. But for development? This is the kind of quality-of-life addition that saves you from hours of Log.d archaeology trying to figure out why your transition is snapping instead of animating smoothly.

Shared element transitions are one of those Compose features that look magical when they work and absolutely maddening when they don't. The problem has always been that the lookahead layout system — which powers the transitions — operates in a way that's hard to observe from the outside. You'd see the end result but have no visibility into the intermediate states.

LookaheadAnimationVisualDebugging changes that by surfacing visual overlays that let you track the lookahead bounds, the actual bounds, and how they're animating relative to each other. It's the kind of tool that makes you go "why didn't this exist from day one?" 😅

If you're building anything with shared element transitions, upgrade to alpha03 and give it a spin. Your future debugging self will thank you.

🤔 Interesting tid-bits

Kotlin Escapes the IntelliJ Mothership 🧰

JetBrains officially released kotlin-lsp — a Language Server Protocol implementation for Kotlin, complete with a VS Code extension. This is huge. For the first time, there's an official path to writing Kotlin outside of IntelliJ/Android Studio with real IDE features: semantic highlighting, navigation, code actions, refactorings, diagnostics, completion, and formatting.

The server is built on top of IntelliJ IDEA and the Kotlin plugin internals, which means it's not some stripped-down toy — it's the real deal running as a standalone server. You can install it via brew install JetBrains/utils/kotlin-lsp and hook it up to any LSP-compliant editor.

The caveats: It's pre-alpha, currently only supports JVM-only Kotlin Gradle projects, and the stability guarantee is literally "none." JetBrains themselves say they "move fast, break things." But the roadmap includes KMP support, Maven/Amper import, and even a "dumb mode" for projects with no build system at all. If you've ever wanted to write Kotlin in Neovim, Helix, or VS Code without feeling like a second-class citizen, your day is coming. 3K stars already and climbing fast.

Vouch: Trust Management for the AI Slop Era 🤝

Mitchell Hashimoto (yes, the Terraform/Vagrant guy) created Vouch — a community trust management system where contributors must be explicitly vouched for before they can interact with a project. It's already in use on Ghostty.

Why does this matter for us Android devs? Because AI-generated PRs are flooding open-source repos, and the traditional barrier of "understanding the codebase enough to submit a change" has evaporated. Vouch creates an explicit web of trust: maintainers vouch for known contributors, vouched users can vouch for others, and projects can even share trust lists. It integrates with GitHub Actions to auto-close PRs and issues from unvouched users.

The vouch list is a simple flat file (.td format — "Trustdown," a play on Markdown) that's trivially parseable. If you maintain any popular Android libraries, this is worth bookmarking.

The issue is: those inputText steps have no target.

In Maestro, inputText types into the currently focused field. If nothing is focused—or if the wrong field is focused—you can end up with:

• email typed into a search box you didn’t mean to focus

• password typed into the email field (and then “Continue” fails)

• password typed into nothing (keyboard dismissed, focus lost)

• tests passing locally because your device happens to keep focus, and failing on CI because focus timing differs

In other words: your test is relying on implicit focus state.

That’s “works on my emulator” energy.

Make it deterministic: tap fields (or target by semantics/text)

A more stable flow explicitly focuses the right elements:

appId: com.example.myapp
---
- launchApp
- tapOn: "Login"

- tapOn: "Email"
- inputText: "[email protected]"

- tapOn: "Password"
- inputText: "superSecretPassword123"

- tapOn: "Continue"
- assertVisible: "Welcome, Alice"

Even better: if your UI uses stable identifiers/labels (especially in Compose), prefer selectors that don’t change with copy tweaks. Maestro supports richer selectors than just visible text; your goal is to anchor on stable UI signals, not marketing’s latest headline experiment.

🦄 How you can help?

If you enjoy reading this newsletter and would like to keep Dispatch free, here are two quick ways to help:

👉🏻 Chip in via Github Sponsors. If your company offers an education budget, contributing a “coffee” to keep this newsletter going will certainly qualify. You’ll get an instant receipt for reimbursement, and I’ll keep Dispatch running ☕️

👉🏻Spread the word. Tweet, Bluesky, toot, Slack, or carrier‑pigeon this issue to someone who loves Android. Each new subscriber pushes Dispatch closer to sustainability.

👂 Let me hear it!

On that note, here’s hoping that your bugs are minor and your compilations are error free,

—