How-To articles

A verified directory of what actually exists for mobile development in Claude Code — skills, plugins and MCP servers — with the corrections that most published lists get wrong and the context cost of installing them all.

Most problems in agent-driven Expo work are setup problems. This is the scaffold to start from, the AGENTS.md template that carries your rules into every session, the eas.json profiles you need, and which MCP servers are worth their context cost.

Expo Go is a preview app, not your app. The moment you add a native module it stops being useful, and that transition catches most projects in week six rather than day two. Here is what actually changes and why to cross it deliberately.

An agent that cannot run your app is guessing. These are the MCP servers that let it build, launch, screenshot and read logs from a simulator or a real device, what each one is actually for, and why to start with one loop rather than five servers.

The question is not which framework is best, but which one an agent writes well. Those are different questions with different answers, and the deciding factors are training coverage, documentation shape and how loudly the framework fails.

Point an agent at Apple’s Human Interface Guidelines and it gets almost nothing back — the page renders client-side. There is a JSON mirror that returns the real content, and this is the verified URL list, plus the Android routing that actually resolves.

Design-to-code demos look convincing and production results rarely match them. This is what Figma MCP actually emits for each mobile platform, the two things that genuinely improve output, and the problem no converter solves.

The design system that produces the best agent output is not the fastest one. It is the one the agent can read. Here is why that is the deciding factor, and how seven mobile options rank against it.

Your rejection notice cites a guideline number and explains almost nothing. This is what Apple actually publishes, which guidelines genuinely catch agent-built apps, and why the statistic everyone quotes about AI apps does not exist.

A reviewer with no memory of writing the code catches what the author cannot. This is how to run one on mobile pull requests, the runner cost trap that surprises people, and an honest account of what it does not catch.

Building a mobile app got very cheap in the last eighteen months. Shipping one did not. This is the ordered path from idea to store listing with Claude Code, including the five cliffs that stop most projects and the compliance work that decides whether you ship at all.

Coding agents write mobile layouts that look right in a screenshot and fail on a real device. The failures are consistent and enumerable: safe-area insets, Dynamic Type, touch-target size and the states nobody screenshots. Here is the full list, with a skill file that encodes the fixes.

Four store rules landing across 2026 catch exactly the app a coding agent builds by default. Each one blocks updates rather than launches, which is why teams meet them late. Here are the dates, what each blocks, and the order to handle them in.

An .ipa is a zip file, and anything you bundled into it ships to every device that installs your app. This is what actually leaks in vibecoded mobile apps, why the widely-blamed anon key is not the problem, and the eight things to fix.

Ask any coding agent for a landing page and you recognise the output before you finish scrolling. The fix is not a better prompt — it is persistent design context. This guide reviews every Claude Code design plugin, skill and MCP server worth your time, and ends with a skill file you can install in one command.

There is no universally correct weekly or monthly app update schedule. This guide gives founders a risk-based release system: how to separate hotfixes, maintenance and product releases, when to hold a build, and which signals should change the calendar.

Deleting an app account does not automatically cancel an Apple or Google subscription. This implementation guide separates identity, personal data, billing and entitlement state so users receive a clear, compliant and testable deletion flow.

Low traffic does not prevent learning; it prevents small-effect A/B tests from resolving quickly. This guide shows indie teams how to select high-information tests, size decisions, combine behavioural and qualitative evidence, and report uncertainty honestly.

User-generated content turns moderation into a continuous product operation, not a policy page. This guide maps preventive controls, reporting, queues, severity tiers, enforcement, appeals, evidence retention, staffing and App Store or Play review readiness.

A healthy global crash rate can hide a severe defect on one popular device family. This runbook shows how to move from Play Console’s device breakdown to variant-aware reproduction, evidence-based mitigation, verified fixes and safe rollout.

Reviews are public product evidence; support tickets contain deeper diagnostic context. This playbook unifies both into a privacy-aware operating loop for incident detection, helpful replies, theme analysis, roadmap evidence and release verification.

A founder-friendly control sheet for the app behaviours most likely to create privacy, billing, account-deletion, UGC, permission, SDK, and review problems on Apple and Google Play.

Play Console is more than the upload screen. This field guide shows founders how to use its overlooked acquisition, testing, quality, release, policy, and financial controls as one operating system.

You shipped an update, the crash rate moved, and now you are trying to work out what you can actually take back. The two stores answer that question very differently: Apple gives you a fixed seven-day ramp you can pause, Google gives you a percentage dial and a halt that works even after full rollout. Neither one removes a bad version from a phone that already has it.

Most Firebase event plans are a list of screens somebody walked through, which is why nobody opens the dashboard six months later. A plan that survives contact with a real product starts from the decision each event is meant to settle, not from the interface. Here is the four-column template we use, and the documented limits that quietly decide what you are allowed to put in it.

You changed a value in the Firebase console, the console says published, and a large share of your users are still on the old behaviour. Nothing is broken. Remote Config has a value priority order, a client cache and an activation step, and each of them is doing exactly what it is documented to do. This is how to read the mechanism, and why a config change still deserves the discipline of a release.

You shipped a bad build, hit halt rollout, and the number of affected users did not fall. That is not a bug — halting a staged rollout and halting a fully rolled-out release are two different operations with two different outcomes, and neither one is a rollback. Here is what each control actually does, why a track’s first release cannot be halted, and how managed publishing changes the shape of the problem before it starts.

Your build is finished, uploaded and going nowhere. Most Play Console blocks are not code problems at all — they are unanswered declarations, and each one has a different owner, a different review queue and a different penalty for getting it wrong. This is the fault tree, taken from Google's own documentation.

Most teams shut an app down by simply stopping work on it, which is the one option neither store lets you take quietly. Apple states plainly that an app you no longer actively support will be removed, and Google Play will not let you delete a monetised app at all once it has installs. This is the sequence that ends an app without stranding the people still paying you.

Two questions get merged into one decision and both get answered wrong. Apple will not let you gate a first launch behind a login unless your app genuinely has account-based features, and Google Play tells you outright that its purchase notifications do not carry complete information about the purchase. One of these questions is a policy constraint; the other is an architecture constraint, and they resolve separately.

Every MVP guide tells you to cut scope until only one feature survives. Neither store has read that guide. Apple and Google both publish a floor below which an app is not a product, and version one has to clear it before a single user sees the listing.

Every stack comparison you have read is a benchmark argument, and benchmarks do not survive contact with your build flags. The decision that actually matters is which documented store constraints your app will run into: download size caps, the startup thresholds Android vitals treats as excessive, how a crash gets attributed, and whether the SDKs your growth stack depends on exist for your framework. Those are all published, and they decide more than framework speed does.

Most idea validation tests whether people want the thing and whether you can build it. It rarely tests the third condition, which is whether the stores will distribute it at all. Apple and Google both publish the rules that decide that, and reading them before you write code is the cheapest validation step available.

Firebase says one install count, your MMP says another, and Play Console says a third. Your event has vanished into a row marked "(other)". Nothing is broken. Firebase is a batched, aggregated reporting system and you are reading it like a database — this is what it is actually doing, and which of the three numbers belongs in a board pack.

You uploaded the build, your colleague installed it in minutes, and the fifty external testers you promised a link to have nothing. Nothing is broken. TestFlight has a documented set of build states, internal and external distribution follow different rules, and almost every "TestFlight is stuck" complaint is one of five states with a named fix.

You submitted on Monday, it is Thursday, and the status has not moved. Apple publishes no review-time commitment, so nobody can honestly tell you how long it will take — but Apple does publish every status your app can be in, and most of them are asking you for something specific. Here is what each one actually means and which ones you are supposed to act on.

Sign-in works on your device, works on the tester’s device, and fails for every real user the day you go live. Nothing in your code is wrong. Google Play re-signs your app with a key you have never seen, and the fingerprint you registered with Google Cloud belongs to a different certificate entirely. Three keys are in play, and knowing which is which resolves this in ten minutes.

Every article about buying installs says "you could get banned" and none of them describes what being banned is. Google publishes four distinct enforcement actions with sharply different consequences — one keeps your ratings, one destroys them permanently, and one takes every account you own. This is what each costs and what survives.

Google publishes exact numbers at which Play begins hiding your app, and most founders have never seen them. This is every current threshold, what they actually measure, why your crash reporter disagrees with Play Console, and the memory and code-optimization vitals arriving in February 2027.

An AI agent can solve a hard problem today and recreate it next month, because the lesson stayed in the conversation instead of the repository. A project bible is the smallest durable knowledge system that stops that happening — eight layers, each one routed, dated and owned, with a check attached to every rule that matters.

A passing test does not prove a bug is fixed unless you know the test would fail when the defect returns. This is the nine-step method we use to close a defect with evidence: define the invariant, reproduce the failure, add a guard that fails, repair at the correct authority, then deliberately reintroduce the bug and prove the guard catches it.

A constant can look reasonable and still be wrong at a boundary. A lookup table can name the right organisation and contain a transcription error. Documentation can describe behaviour the app stopped performing two releases ago. This is the method we use to turn every real-world claim in a product into something you can re-run on demand.

Part 11 of our AI product development methodology series. A screen-by-screen review can confirm that every form, chart and report works while missing the defect that connects them. The deeper unit of audit is data — pick the three objects whose corruption would hurt most, then name every path that can create, change or destroy them.

Code review can confirm that a colour token was used. It cannot tell you whether the screen feels balanced, whether the heading wraps badly at accessibility text sizes, or whether the success message disappears before anyone reads it. This is part 10 of the AI Product Development Methodology series: the four evidence layers a real audit needs, and the rule that stops one layer closing another layer’s claim.

Give an AI coding agent a beautiful screenshot and it will reproduce the visible surface while quietly breaking everything the screenshot cannot show — normalised units, edit identity, offline retries, entitlement checks, accessibility order. This is the five-contract, nine-phase workflow we use to turn an approved design decision into a bounded patch instead of an uncontrolled reconstruction.

The quality of an AI audit depends far less on how forcefully you ask for expertise than on what evidence you require. This is the eight-part prompt contract we arrived at after repeatedly auditing a real iOS and Android product and watching broad, confident prompts declare finished areas that were not finished.

The strongest AI-assisted workflow does not ask one tool to think, design, build and verify. It splits four responsibilities — strategic synthesis, visual exploration, repository execution and independent verification — and defines what evidence each one is allowed to produce. This is part 7 of the AI Product Development Methodology series.

Design boards are useful when they make decisions visible and dangerous when they make speculation look implemented. This is the bounded, screen-by-screen board method we used on a real iOS and Android product: one surface, one question, every state that matters, a fixed evidence pack, and a runtime comparison that decides whether the board was right.

Most redesigns start with the first screen someone opens, which is how a product ends up with twelve individually improved surfaces and no centre. A UI/UX strategy is the decision system that comes first: nine layers that turn product evidence into rules a designer, a reviewer or an AI agent can be held to. This is the method, with the one-page charter and the prompt we use to produce it.

Most audit folders contain hundreds of images and almost no evidence: polished happy paths, inconsistent crops, no error states, and design concepts sitting unlabelled beside production captures. This is the method we use instead — choosing every screenshot backward from the claim it has to prove.

Before you redesign anything, you need proof of what exists — not a sitemap, not a folder of attractive screenshots. This is the seven-register inventory method we used to map a product with 51 screens and seven sheets on one platform alone, and still find unreachable capabilities, missing recovery states and data changes with no edit button anywhere in the interface.

The first instruction you give an AI agent on an existing product should be an instruction to investigate, not to improve. This is the discovery method we run before any AI-assisted audit, redesign or implementation: eight artefacts, nine steps, and an evidence label on every claim.

AI can make a product look finished in a weekend. Looking finished and being trustworthy are different states, and only one of them survives contact with users. This is the ten-stage method we settled on for using AI to investigate broadly while letting evidence — not confidence — decide what is true.

Most teams pay for a product analytics tool a year before they need one, and then never instrument it properly. This is a vendor-by-vendor comparison of the mobile analytics tools worth using — Firebase, Amplitude, Mixpanel and PostHog — with every free-tier allowance checked against the vendor's own pricing page as of August 2026, and a plain answer on when free is genuinely enough.

We built and shipped an iOS app almost entirely through Claude Code. Eight of the ten critical review findings sat in persistence, sync and account identity — and not one sat in the UI we were watching every day. Here is the rules file, the review loop and the audit prompt that came out of it, and the failure behind each one.

Almost no app dies of one dramatic failure. It dies of a sequence: nobody found it, the few who did left on day one, and the numbers were too small and too flattering to show either problem in time. This is the failure taxonomy we have watched play out across a decade of launches, and the parts of it you can still fix.

A soft launch is not a bigger beta. It is a paid, live, revenue-generating test of whether your app can be bought profitably — run in a market small enough that being wrong is cheap. Here is how to pick the market, size the spend, and write the go and no-go gates before you start.

Both stores document their own submission flow well. What neither documents is the sequence — which decisions are permanent, which paperwork has a month-long lead time, and which step is the one that actually delays first launches.

A rejection is a paragraph of guideline text and no explanation of what to change. Six guidelines account for most first-submission rejections, and every one of them is avoidable before you submit — if you know what the reviewer is actually looking at.

If you opened a personal Play Console account after November 2023, you cannot publish to production until 12 testers have stayed opted in for 14 straight days. Most developers lose weeks to this rule because nobody explains how the clock actually works — or why buying testers is the fastest way to lose the account.

Most AI coding tools are a single agent improvising. AI App Studio is a structured 17-role team — CEO, engineers, code reviewer, QA, release manager — that takes your one-line idea from scope to shipped iOS and Android app, with two human gates and everything else running autonomously. This is the full playbook on what it is, how it works, and why it changes the economics of shipping mobile apps.

Agentic Android development is not autocomplete by another name. This guide covers exactly how to install Claude Code, configure a production CLAUDE.md, choose the right skill packs, and run real Kotlin/Compose workflows — including the honest pain points every Android team hits first.

Android migration backlogs stall because mechanical converters map syntax, not idioms. This guide shows how Claude skills — for XML-to-Compose translation, state hoisting, performance, and Java-to-Kotlin modernisation — collapse a six-month migration into weeks of focused, reviewable work.

Claude can write Android code, but without the right tooling it cannot see the running app. Wiring Maestro MCP, OpenTester, and ADB MCP servers into Claude Code closes that device-visibility gap — turning the agent into a QA engineer that writes, runs, and triages tests end-to-end.

A single CLAUDE.md silently degrades beyond 15-20 Gradle modules. This guide covers the three additional axes — subagents, skills, and MCP servers — that turn Claude Code into a teammate that actually scales to a 50-engineer Android org.

Xcode 26.3 shipped the Claude Agent SDK as a first-party integration — not a plugin, not a beta. This guide covers the complete setup: built-in MCP, XcodeBuildMCP, AXe simulator control, the ios-simulator-skill, and the CLAUDE.md template that closes the visual preview loop.

Shipping is the bottleneck — not code quality. This guide walks through the complete pipeline: SwiftUI skills, App Store Connect MCPs, fastlane automation, screenshot generation, and Apple policy minefields every Claude-assisted iOS project needs to navigate in 2026.

UIKit migration sits on every iOS backlog like a tax bill nobody wants to file. With Claude Code, the right skill scaffolding, and a disciplined build-and-verify loop, individual screens now migrate in an afternoon — not two sprints. Here is the 2026 playbook that makes it tractable.

Compare AppsFlyer, Adjust and Singular using published pricing and a practical evaluation checklist. Learn what to test before choosing an MMP, how to validate revenue events, and how to plan a migration.

A practical subscription operating system for founders: choose the value boundary, test paywalls and trials, localise pricing, model store fees, recover billing failures, and read cohorts without inventing universal benchmarks.

A well-engineered referral programme can make every new user you acquire bring in another — lowering your blended CPI, raising LTV, and compounding growth exponentially. This guide covers the K-factor formula, incentive design, WhatsApp-first sharing in India, fraud prevention, and how referrals fit alongside a paid UA stack.

LTV-to-CAC ratio is the single most important number for app marketing decisions. Here is how to calculate it correctly, the benchmarks for your category, and what to do when the ratio breaks.

The iOS-vs-Android launch decision is rarely simple. Here is the decision framework — based on market share, monetisation, geography, development cost, and store policy.

Most launches under-perform because marketing starts at launch. The 30 days before launch are when most of the leverage actually lives. Here is the playbook.

The single most common founder question we get is "how much should I budget for marketing?" Here are honest year-1 budget benchmarks by stage and vertical for India.