Building Android apps with Claude Code

Anthropic's description is short and worth reading literally:

"Claude Code integrates with JetBrains IDEs through a dedicated plugin, providing features like interactive diff viewing, selection context sharing, and more."

Install it from the JetBrains Marketplace and restart. It does not bundle its own copy of Claude Code — "it runs the `claude` command in your IDE's integrated terminal and connects to it."

So what you get is a better terminal experience. Diffs render properly instead of scrolling past. The agent knows what you have selected. That is real and it is useful.

What you do not get is the agent operating the IDE. The only tool exposed to the model is diagnostics, and Anthropic states the limit rather than leaving you to discover it: the plugin does not expose a code-execution tool.

In practice that means Claude Code will write Kotlin for you very capably — this is not a criticism of the model — and you will be the one running Gradle, reading what broke, and pasting it back.

The asymmetry is not Anthropic's doing. It is Apple's.

Apple built and ships xcrun mcpbridge, which hands an external agent access to Xcode's own capabilities:

claude mcp add --transport stdio xcode -- xcrun mcpbridge

In the Xcode 27 beta that bridge widens further — the release notes describe tools for manipulating the run state, reading the debugger console, switching schemes and run destinations, and inspecting and modifying build settings, compiler flags, entitlements and Info.plist keys.

Google has not built the equivalent for Android Studio, because Google built something else instead: their own agent, inside the IDE. Which is a reasonable strategy, and it means the honest comparison is not "Claude Code on iOS versus Claude Code on Android" but "Claude Code plus Apple's bridge, versus Gemini in Android Studio."

We cover the iOS side in detail on agents in Xcode, including which capabilities have actually shipped and which are still beta-only.

If your goal is an Android app and you are choosing tooling today, Google's Agent Mode deserves a serious look before anything else. Their description:

"Gemini in Android Studio's Agent Mode is designed to handle complex, multi-stage development tasks. You can describe a high-level goal, and the agent creates and executes a plan, invoking the necessary tools, making changes across multiple files, and iteratively fixing bugs."

And the capability that matters:

"The AI agent in Android Studio has access to tools to deploy an app to the connected device, inspect what is shown on the screen, take screenshots, check Logcat for errors, and interact with the running app through adb shell input."

Deploy, look, tap, read the logs, fix. That is a closed verification loop, it is in the stable IDE, and it arrived before Apple shipped the same thing — Xcode's simulator control is still an Xcode 27 beta feature.

There is a build-fix loop too: ask it to fix build errors and "it applies a recommended fix, builds the project to verify the solution, and iterates until the issue is resolved." You can steer its behaviour with an AGENTS.md file, the same pattern as CLAUDE.md.

We are not the vendor here and have no reason to undersell it. If you want one Android app and nothing else, this is a strong, free, first-party option.

Everything above assumes one platform. The moment you want the same app on iOS and Android, the tooling story stops helping.

You have two IDEs, two languages, two agent integrations with different capabilities, and — the expensive part — two implementations of the same business logic that will drift. Not dramatically, and not at first. But the iOS version handles the empty state one way, the Android version another, someone fixes a bug on one platform, and six months later "the same app" is two apps that mostly agree.

Reconciling that is manual work forever. It does not show up in a demo and it is most of the cost of shipping on both platforms.

The usual answers each give something up. A cross-platform framework shares the logic by sharing the runtime, so both interfaces render through the same engine rather than the platform's own. Writing both natively keeps each interface real and gives you the drift problem back.

Duet is Modaal's answer, and the idea is narrow enough to state in a sentence. From the documentation:

"Each feature's logic — its state, the actions that change it, the effects it requests — is written once. The iPhone app renders that state in SwiftUI; the Android app renders it in Jetpack Compose."

The interfaces stay genuinely native. Each app "follows its own platform's conventions — Apple's Human Interface Guidelines on one side, Material 3 on the other." Nothing renders through a shared engine.

The part that makes it more than an intention is the enforcement:

"Behavior is recorded as fixture files. Both platforms replay the same fixtures and the gate is byte equality."

The build fails when the two platforms stop agreeing. Drift is not something you notice in review three months later; it is something that breaks CI on the commit that caused it.

Android is in open beta, with general availability in September 2026. You can join the beta now.

And Claude Code is one of the agents Modaal runs on — alongside Codex CLI, Cursor, Gemini CLI, GitHub Copilot CLI, OpenCode, OpenHands, Mistral Vibe and others. You authenticate with the Claude subscription you already have. Modaal adds no per-token charge.