July 15, 2026
Claude Code for Mobile Developers
A Best-Practice Setup

By Mobile@Exxeta
11 min read
How we set up Claude Code at Mobile@Exxeta: from pricing and model selection to the skills, plugins, and configuration that make a measurable difference on mobile codebases.
Claude Code has become one of the most capable CLI-based coding agents available, but out of the box it is unconfigured, and on a mobile project that matters more than usual. iOS and Android codebases are large, slow to build, and full of platform-specific structure: Xcode and Gradle toolchains, generated code or even shared Kotlin Multiplatform modules feeding two native UIs. Without setup, Claude Code tends to either load context it does not need, which costs money, or make changes that cross the module boundaries you wanted it to respect.
This article covers how we set up Claude Code at Mobile@Exxeta: how to think about cost, which model to use for which task, and the skills, plugins, and configuration that pay off on a mobile codebase. It also covers one that introduces real security risks.
First: How Does Claude Code Actually Work?
Claude Code runs in your terminal, not in a chat window you copy and paste into. It is an agentic coding environment with direct access to your filesystem, shell, and version control. It reads your codebase, runs commands such as Gradle and xcodebuild builds, test suites, git operations, creates and edits files, and can spawn subagents to parallelize work, for example handling the Android and iOS sides of a shared change at the same time.
Every interaction consumes tokens, billed to either a subscription plan or your API key.
Subscription vs. API: What's Right for You?
This is the first decision, and it is mainly about money. Claude Code can be billed two ways: through a subscription with a fixed monthly price and usage caps, or through an API key that bills per token with no fixed ceiling.
Subscription plans give you a flat monthly fee and a built-in usage budget. As of June 2026, the relevant tiers are Pro at $20/month, Max 5× at $100/month, and Max 20× at $200/month, with Team Premium at $100/seat for organizations (Anthropic pricing). Pro suits lighter, occasional sessions. Max is the practical choice once Claude Code is your primary tool for several hours a day, because it raises the usage quota substantially. The tradeoff is that subscriptions enforce caps: a rolling usage window and a weekly limit that can interrupt you mid-session during heavy use.
API key usage bills purely per token, with no monthly ceiling and no session quota. As of June 2026, the standard rates are:
+------------------+--------------------+---------------------+
| Model | Input ($/M tokens) | Output ($/M tokens) |
+------------------+--------------------+---------------------+
| Claude Haiku 4.5 | $1 | $5 |
+------------------+--------------------+---------------------+
| Claude Sonnet 4.6| $3 | $15 |
+------------------+--------------------+---------------------+
| Claude Opus 4.8 | $5 | $25 |
+------------------+--------------------+---------------------++------------------+--------------------+---------------------+
| Model | Input ($/M tokens) | Output ($/M tokens) |
+------------------+--------------------+---------------------+
| Claude Haiku 4.5 | $1 | $5 |
+------------------+--------------------+---------------------+
| Claude Sonnet 4.6| $3 | $15 |
+------------------+--------------------+---------------------+
| Claude Opus 4.8 | $5 | $25 |
+------------------+--------------------+---------------------+Source: Anthropic pricing
Per-token billing looks cheap until you account for context. On a large mobile codebase, a single session can load tens of thousands of tokens before your first real request, once the project files, CLAUDE.md, installed skills, and MCP schemas are all in context. With API billing there is no cap on that, so an unattended or multi-agent session can run up a bill quickly.
The practical rule: start with Pro if you use Claude Code occasionally. If you run active sessions for several hours a day, Max 5× at $100/month is the usual choice. Independent cost analyses put a heavy single-developer profile, roughly 3–5 hours per day, at about 2 to 2.5× cheaper on Max than on equivalent API billing, with the added benefit of avoiding mid-session caps (Verdent cost guide). If you run Agent Teams or all-day agentic workloads, estimate carefully: a multi-agent session can consume several times the tokens of a single-agent one, which shifts the math back toward measuring your own usage before committing.
A note for heavy API users. If you bill per token and work in large repos, a real chunk of spend is Claude reading — file contents and verbose shell output. Tools like LeanCTX (yvgude/lean-ctx) run locally between the agent and your repo and compress those reads, claiming 60–90% fewer read tokens with near-free cached re-reads. The caveat that matters: this mainly helps API billing. On a Pro or Max subscription the wire-compression proxy cannot run against Anthropic's OAuth login, and your constraint there is quota, not dollars, anyway.
Models and Effort Levels: Which to Use When
Per-task model choice is the highest-ROI setting in Claude Code. At API rates Opus costs roughly 5× Sonnet per token, so don't run the frontier model for everything.
Rule: plan with Opus, execute with Sonnet. Enter plan mode (Shift+Tab) on Opus, review the plan, then /model sonnet to build.
For occasional Opus input during execution without a full switch, /advisor keeps Opus on call when Sonnet stalls (Claude Code model config docs).
+--------------------------------------------------------------+------------+----------------------+
| Task | Model | Why |
+--------------------------------------------------------------+------------+----------------------+
| KMP shared-module API design, hard concurrency bugs, | Opus 4.8 | Reasoning depth |
| wide cross-platform refactors | | |
+--------------------------------------------------------------+------------+----------------------+
| Screens, ViewModels, unit and UI tests, most feature work | Sonnet 4.6 | Best price/quality |
+--------------------------------------------------------------+------------+----------------------+
| Renames, log lines, data-class boilerplate, quick lookups | Haiku 4.5 | Cheap mechanical work|
+--------------------------------------------------------------+------------+----------------------++--------------------------------------------------------------+------------+----------------------+
| Task | Model | Why |
+--------------------------------------------------------------+------------+----------------------+
| KMP shared-module API design, hard concurrency bugs, | Opus 4.8 | Reasoning depth |
| wide cross-platform refactors | | |
+--------------------------------------------------------------+------------+----------------------+
| Screens, ViewModels, unit and UI tests, most feature work | Sonnet 4.6 | Best price/quality |
+--------------------------------------------------------------+------------+----------------------+
| Renames, log lines, data-class boilerplate, quick lookups | Haiku 4.5 | Cheap mechanical work|
+--------------------------------------------------------------+------------+----------------------+Subagents. The built-in Explore agent already runs on Haiku by default. For your own custom subagents that don't specify a model in their frontmatter, you can set them to default to Haiku as well — since fast, cheap models are usually sufficient for read/search-heavy tasks. Add this to your settings:
{ "env": { "CLAUDE_CODE_SUBAGENT_MODEL": "haiku" } }{ "env": { "CLAUDE_CODE_SUBAGENT_MODEL": "haiku" } }Effort levels (Opus 4.8). low, medium, high (default), xhigh, max — set with /effort or the /model slider. Higher effort spends more output tokens to reason harder. Raise it for architecture, lower it for routine work; leaving it high by default is a quiet cost.
Prompt caching. Automatic when context is reused; cached input bills at ~10% of the normal rate (Anthropic pricing). Staying in one session re-reads CLAUDE.md and file context from cache instead of re-billing each turn.
CLAUDE.md: Your Highest-Leverage Config File
CLAUDE.md loads at the start of every session and stays in context for every message, which makes it both your most useful configuration and your biggest avoidable cost. Put in it what Claude cannot infer from the code:
- Stack and module layout (shared/, androidApp/, iosApp/)
- Conventions and architecture (MVVM+Contract, expect/actual rules, DI)
- Key commands (Gradle tasks, test commands, how iOS builds)
- What to avoid — the constraints that cost debugging time when broken
Keep it lean. Official guidance is blunt: for each line, ask whether removing it would cause a mistake; if not, cut it, because bloated files make Claude ignore the rules that matter (Claude Code best practices). Community consensus lands at a couple hundred lines or fewer. If Claude can learn it by reading the codebase, leave it out.
Scope the rest. Anything not universally relevant belongs in path-scoped rule files (.claude/rules/, pulled in with @imports) or in skills — both load only when relevant instead of riding in context every turn. In a KMP repo this maps cleanly: a lean root CLAUDE.md plus per-module rules for shared/, androidApp/, and iosApp/.
Use hooks for hard rules. CLAUDE.md is advisory — Claude treats it as guidance, not a guarantee, and is likelier to drop rules as the file grows. For things that must happen every time — ktlint, detekt, SwiftLint — use a hook, which runs deterministically every edit.
Keep it current. Treat it like code: prune it when behavior drifts and update it whenever the project changes. A stale CLAUDE.md is worse than a short one.
If more than one agent touches the repo (Codex, Cursor, Gemini CLI), keep one source of truth and symlink AGENTS.md to CLAUDE.md — every tool reads the same file instead of drifting out of sync.
Example root CLAUDE.md for a KMP app:
# MyApp - Kotlin Multiplatform
## Modules
- shared/ KMP logic, Room, Ktor (Android + iOS)
- androidApp/ Jetpack Compose
- iosApp/ SwiftUI, consumes shared via XCFramework
## Conventions
- MVVM + Contract; ViewModels live in shared/, not platform modules
- No platform code in commonMain - use expect/actual
- DI via Koin
## Commands
- Build shared: ./gradlew :shared:build
- Android tests: ./gradlew :androidApp:testDebugUnitTest
## Avoid
- No commonMain deps without checking iOS compatibility
- Don’t edit generated XCFramework bindings# MyApp - Kotlin Multiplatform
## Modules
- shared/ KMP logic, Room, Ktor (Android + iOS)
- androidApp/ Jetpack Compose
- iosApp/ SwiftUI, consumes shared via XCFramework
## Conventions
- MVVM + Contract; ViewModels live in shared/, not platform modules
- No platform code in commonMain - use expect/actual
- DI via Koin
## Commands
- Build shared: ./gradlew :shared:build
- Android tests: ./gradlew :androidApp:testDebugUnitTest
## Avoid
- No commonMain deps without checking iOS compatibility
- Don’t edit generated XCFramework bindingsSkills, Plugins, and MCP: What's What
These three get conflated constantly, so to be precise:
- Skill — a SKILL.md file (plus optional scripts) that teaches Claude one behavior. Only its name and description sit in context; the body loads when the task is relevant.
- Plugin — an installable bundle from a marketplace that can contain skills, slash commands, hooks, subagents, and MCP servers (Claude Code best practices).
- MCP server — a connector to external systems (GitHub, Linear, Jira). Covered in its own section below.
So "skill vs plugin" is not either/or: a plugin is just a delivery mechanism that often ships one or more skills.
Mobile-specific skills are the real win
For a mobile team, the skills worth installing are the platform-specific ones. A few community collections:
- apple-skills — Apple-platform skills including swift-concurrency, swiftui, swift-testing, swiftdata, and storekit, targeting current iOS APIs.
- ECC (Everything Claude Code) — Huge collection of specific skills, some of them for mobile, e.g. swift-concurrency-6–2, swiftui-patterns or kotlin-coroutines-flows.
Install from the relevant marketplace, for example claude plugin marketplace add then claude plugin install . These are third-party, so read the SKILL.md before installing — the same scrutiny applies as to plugins.
Caveman: a general-purpose token saver
Worth knowing but not mobile-specific. Caveman, by Julius Brussee, makes Claude reply telegraphically — dropping articles, filler, and pleasantries while keeping code and technical terms exact. The repo benchmarks about 65% fewer output tokens (range 22–87%). The honest caveat: output is a minority of total session tokens, so real session-level savings are smaller, in the single to low-double digits. The bigger everyday benefit is faster, less cluttered responses. A companion, caveman-compress, rewrites your CLAUDE.md into compressed form to cut input tokens too. Pro tip: Configure it as a SessionStart hook so it is automatically invoked on every session start.
Plugins: Power, and a Cautionary Tale
Plugins are where Claude Code gains most of its extra capability — and most of its risk.
Superpowers — discipline, not magic
The most-adopted plugin in the ecosystem is Superpowers, by Jesse Vincent (Prime Radiant): launched October 2025, accepted into Anthropic's official marketplace in January 2026, and now past 170k GitHub stars (obra/superpowers). Its premise is that agents lack discipline, not capability — left alone, Claude races ahead on a vague description and builds confidently in the wrong direction. Superpowers enforces a workflow before any code is written: brainstorm → design → plan → implement (TDD) → review. The value is in the planning phase; reviewing a plan before approving it catches more than any after-the-fact review. On a KMP codebase that often means catching a change that would have crossed your shared-module boundary before it is written.
Install from the official marketplace: /plugin install superpowers@claude-plugins-official
GSD — why you vet what you install
GSD (Get Shit Done) was another popular workflow framework, spec-driven and token-efficient through fresh subagent contexts. Then it became a cautionary tale. In May 2026 the project's maintainer went silent and deleted their accounts, and the associated $GSD crypto token was publicly linked to a rug-pull. A community fork (open-gsd on GitHub) took over the codebase; the original npm packages remain live and unmaintained. The careful version of the story matters: the fork maintainers themselves note they cannot confirm intent versus a compromised account — what is documented is the token rug-pull, the deleted accounts, and the silence. If you have the original installed, move to the community fork and remove the old npm packages.
Plugin security is a real attack surface
GSD is the soft version of the risk; the hard version is documented. Plugins can ship hooks (code that runs on Claude Code events), and a project's checked-in .claude/settings.json is read before you are asked to trust the repo. Researchers have shown a malicious marketplace plugin rewriting the permissions file via a hook to auto-approve commands, then exfiltrating code through a prompt injection (PromptArmor). Assigned CVEs follow the same pattern — a hostile .claude/settings.json achieving remote code execution or harvesting your API key before the trust prompt (Pluto Security). Public registries such as claudecodemarketplace.com state outright that they do not verify plugins.
Practical hygiene:
- Prefer Anthropic's official marketplace or audited, well-known repos.
- Before installing, check maintainer history and read what hooks and permissions the plugin registers.
- Audit .claude/settings.json on any repo you clone — treat it as executable.
- Keep Claude Code updated; several of these holes were closed in point releases.
- Consider Anthropic's official security-guidance plugin, which reviews Claude's own code changes for vulnerabilities as you work (docs).
MCP: Connecting Claude Code to Your Stack
Plugins extend what Claude Code can do; the Model Context Protocol (MCP) extends what it can reach. MCP servers are connectors that give Claude Code tools and data from external systems, turning it from a file editor into something that works across your whole workflow. Servers are configured per project in .mcp.json or per user in ~/.claude.json.
For mobile teams the useful integrations map to where the work lives:
- Issue trackers (Linear, Jira) — read a ticket, implement it, link the PR.
- Version control / CI (GitHub, Gitlab) — triage issues, open PRs, check why a build failed.
- Design (Figma) — pull a screen's specs or tokens straight into the implementation.
- Monitoring (Sentry) — feed in a crash or stack trace and have Claude trace it to the code.
Treat MCP servers like plugins, or more carefully. An MCP server is a subprocess running with your privileges and network access, and its tool descriptions enter Claude's context — itself an injection surface. Documented MCP risks include tool poisoning, server "rug pulls," and credential theft (awesome-claude-code-security). Two practical rules: scope MCP permissions at least as tightly as your bash rules, since a broad database or shell tool inherits whatever trust you grant it; and watch for connector composition — a low-risk connector plus a high-risk one in the same session is a larger attack surface than either alone (Pluto Security)
Where to Go From Here: Academy and Certification
Anthropic now runs structured learning around Claude. Anthropic Academy (launched March 2, 2026) is a free, self-paced course catalog on Skilljar — 13 courses at launch — covering the wider Claude ecosystem. The ones relevant to this article are Claude 101, Claude Code in Action, Introduction to Agent Skills, and Introduction to MCP (Anthropic Academy).
For something more formal, the Claude Certified Architect (CCA), Foundations is Anthropic's first official technical certification (announced March 12, 2026). It is a 60-question proctored exam spanning five domains — agentic architecture, Claude Code configuration, prompt engineering, tool design and MCP, and context management and reliability. The first two map directly to the setup territory this article covers. The exam runs through the Claude Partner Network (Claude Partner Network).
Finally: The Setup Is a Moving Target
One caveat ties all of this together: none of it is static. Anthropic ships new Opus versions on roughly quarterly cycles, each bringing capability and occasionally tokenizer changes, and the surrounding ecosystem — skills, plugins, marketplaces — moves even faster. The pricing, the model matrix, and the specific tools in this article will all need revisiting; treat them as a snapshot, not a permanent answer. Build the habit of checking release notes before a major project.
What does not change is the shape of a good setup: spend deliberately, keep your context lean, give Claude the conventions it can't infer, plan before you build, and vet anything you install. Get those right on your mobile codebase and Claude Code stops being a blank slate and starts behaving like a teammate who already knows the project. (by Benedikt Betz)