Part 1 covered the fundamentals - how CLAUDE.md works, why shorter is better, and the structure that actually gets followed. This part is about what to add when your app itself uses AI and the mobile-specific things, so your app doesn’t get hacked or your data doesn’t get leaked or something worst.
If your app makes AI calls, document the boundary
This is the most important section to get right. And the principles are the same whether you end up using OpenAI, Gemini or something else.
Put all AI calls in one place
Pick a folder -
ai/, services/ai/whatever fits your structure - and make it the only place in the codebase that talks to an AI provider. Document this explicitly in CLAUDE.md. All AI provider calls live here. This matters because AI outputs are probabilistic. The code that validates and handles those outputs - the deterministic shell around the AI - needs to be centralized. If Claude can casually add AI calls anywhere in the codebase, that shell falls apart.
Decide how you’ll use models (before you pick one)
You don’t need to pick a provider to decide how you’ll use models. The logic is usually simple. Cheap, fast models handle classification, tagging, and basic Q&A. More expensive models are for when reasoning actually matters. Put that logic in config and point Claude to it.
Always validate AI output
Treat model output like user input. Before it renders, gets stored, or gets passed anywhere else, it should go through a schema. If you’re in TypeScript, Zod is the obvious choice. Also worth stating explicitly: don’t show raw output directly to users, and don’t execute anything the model suggests without a confirmation step.
Stop rewriting AI error handling everywhere
AI failures aren’t clean. You’ll hit rate limits, timeouts, and responses that fail validation. The easiest way to keep this sane is to route everything through a shared handler. Define it once, and make sure Claude uses that instead of writing new handling logic every time it touches AI.
Treat prompts like code
Inline prompts feel fine at the start, but they don’t scale. Store them in one place, give them names, version them when you change them. It sounds like overhead until something breaks and you have no idea what changed. Versioning prompts is what lets you trace behavior instead of guessing.
Mobile-specific things worth calling out
Most CLAUDE.md advice is written with web apps in mind. Mobile has a different set of constraints, and Claude won’t always infer them correctly.
Start with platform scope. Whether you’re building for iOS, Android, or both and whether tablets are in scope, affects a lot of downstream decisions. It’s better to make that explicit upfront.
Environment handling is another one that gets messy on mobile. Variables might live in .env, app.config.js, or something like EAS secrets. Claude shouldn’t assume web style setups here.
If your app uses native modules - camera, push notifications, biometrics, payments, it’s worth listing them. These come with platform specific quirks and sometimes OS-level limitations. Claude should know what’s already in play before suggesting alternatives.
If you’re using OTA updates (like Expo Updates), there are limits. JavaScript and assets can update over the air. Native changes can’t. Without that context, Claude might suggest something that simply isn’t deployable the way it assumes.
And then there’s app store policy. Both Apple and Google have started caring more about AI-generated content. If your app surfaces AI output, there may be disclosure requirements. Worth documenting so you don’t accidentally build something that gets flagged in review.
The security section: what CLAUDE.md can’t actually enforce
This is where a lot of guides oversell things.
Writing “never commit API keys” in CLAUDE.md helps, but it’s not a guarantee. It’ll work most of the time, until it doesn’t - context pressure, long sessions, edge cases. CLAUDE.md is still just a prompt. Prompts can be ignored. The actual enforcement layer is hooks, shell commands that run before or after Claude takes an action. A hook that blocks a file write exits with a specific code that Claude cannot override, even in its most permissive mode. The simple rule: preferences go in CLAUDE.md, things that must never happen go in hooks. A few examples of how that works in practice:
| What you want | Advisory (CLAUDE.md) | Enforced (hook) |
|---|---|---|
| No secrets in code | “Never hardcode API keys” | Scans file content for secret patterns before every write |
| No destructive commands | “Avoid rm -rf” | Blocks matching bash commands before they run |
| Tests before a PR | “Run tests before committing” | Runs test suite before any PR creation |
For mobile specifically: keep your signing certificates, provisioning profiles, and EAS credentials completely out of the repo and out of Claude’s reach. Document where they live and that Claude should not touch them.
CLAUDE.local.md - still useful
This is your personal layer. Gitignored, loaded after the main file. Temporary context that’s genuinely helpful but has no place in the shared file, but doesn’t mean you shouldn’t be taking notes - save them here.
The thing that doesn’t change
CLAUDE.md is an instruction budget. Every line takes up space in that budget, so it should be reserved for things Claude genuinely can’t infer - your boundaries around AI, your validation rules, your platform constraints. Everything else, it can figure out by reading your code.