How to build mobile apps with AI: the three tools that actually matter

The short version: To build mobile apps with AI, you need three tools. Skills are instruction files (a single SKILL.md) that an AI coding agent reads only when a task needs them, so they cost almost nothing in context. MCP servers connect the agent to external services like your build dashboard so it can read logs and drive a simulator, at the cost of loading every tool definition up front. The AI workflow is how you manage the conversation itself: keep each one under ~50% of the context window and branch threads by task. Add skills first, connect one MCP, then watch your context. The rest of this post shows how, using a habit tracker as the running example.

In this post, I'll share everything you need to know to build powerful mobile apps with AI. There are tons of tools out there, but most of them aren't really useful - except for three, which we'll be diving deep into today: skills, MCP servers, and the AI workflow that ties them together. I'll show you how to set up each one and when to reach for it, while we lay the foundations for the habit tracker we'll be building together.

Start by scaffolding a project with create-expo-app. You can use bunx or npx, it doesn't matter which - and if you want a different starting point, there are hundreds of other starter templates to pick from:

bunx create-expo-app@latest habit-tracker
cd habit-tracker
bun install
bun start

That gives us a running app with the default tabs. They work, but they're the old style. We want the native liquid glass effect on the bottom tabs, and that's where the first tool comes in. Read on to learn more about each tool, or watch my video where I cover all this same content:

Skills: instruction manuals for your AI

A skill is a folder of instructions an AI coding agent reads when a task calls for it. The only thing it needs is a single SKILL.md file - you can also add references for more documentation and scripts for running code, but the markdown file alone is enough. Skills work across agents that support them, including Claude Code, Cursor, and Codex.

The Expo team maintains a set of skills for building and shipping React Native apps, and the community has built plenty more. Browse them at expo.dev/skills, or grab the whole set from the expo/skills repo. To install, copy the command from the skills page and run it in your terminal. When it asks which skills you want, you can pick them one by one, or add all of them with a wildcard:

npx skills add -s "*"

Next it asks which coding agent should use them. Most agents read from an agents/ directory, but Claude Code has its own convention, so add that explicitly if that's what you're running. Then it asks about scope: should these skills live only in this project, or be available in any directory? Keep them scoped to the project unless you build mobile apps every single day, in which case, respect, and use symlinks. After that you'll see an agents/ directory and a .claude/ directory populated with your new skills.

If you want to understand what makes a skill good, Anthropic published a guide to authoring skills that covers everything. The one idea worth internalizing now is progressive disclosure: don't load information until there's a reason to load it. A skill exposes a short description up front, and the full instructions only get pulled in when the task calls for them. That principle is the reason skills stay cheap on context, and it comes back later in this post.

Two ways to invoke a skill

The first way is explicit. You call it by name as a slash command:

/expo-ui

That tells the AI to read the SKILL.md inside that skill before it does anything. (In Codex the prefix is a $ instead of a /.) Let's use it on our tabs:

/expo-ui Please implement the liquid glass effect inside the bottom tabs.

The second way is autonomous. Every skill carries a description, and the AI uses it to decide on its own whether the skill is relevant to what you asked. In other words, every description gets loaded into every single conversation. That's why you shouldn't hoard skills: too many, and those descriptions start bloating up your context window - something we'll talk more about later.

Take a look at our tabs before and after we used the skill.

Look at that: a clean one shot, all with one skill.

Let the AI find its own skills

Before moving on, we want performance and best practices covered. Writing a skill for that is possible, but someone has probably already done it. So ask:

Can you help me find a skill that ensures the app is always
performing at its best and nothing is slowing it down?

The AI invoked a find-skills skill on its own, without being told, because that one lives in the global config. It's the first and most-installed skill on skills.sh, a directory that searches across roughly 900,000 community skills. The find-skills skill itself is literally just one file - very simple, but powerful. Once it recommends one, tell it to install locally and it handles the rest.

There's a lot more we could dive into here, but this should give you a head start to make real progress with skills.

MCP servers: give the AI hands outside the editor

You'll hit the limit of skills the moment the AI needs information it can't see from the codebase. That's exactly what happened next: I pushed my changes so others could use the app, and the build failed - I wasn't sure why. The logs don't live locally, they're in the Expo dashboard. And I couldn't be bothered to go there and read it. So what if the AI could read the logs in my dashboard and implement a fix autonomously?

That's what MCP does. MCP (Model Context Protocol) is an open standard that connects an AI agent to external services (Notion, Supabase, GitHub, your build dashboard) so it can both read data and take actions on your behalf. The Expo MCP server exposes your EAS builds, workflows, logs, and crash reports. As of a recent change it's free for everyone, where it used to be a paid-plan feature.

Get it from expo.dev/ai, which has the install scripts and a deeper walkthrough. We also have a whole video on the Expo MCP that's still worth watching - just keep in mind it was made back when the MCP was reserved for the paid plan. If you're on Claude Code, copy the script for it. You can also install the Expo plugin, which bundles both the skills and the MCP server. You'll know it's been added when you see this in your Claude settings.json:

{
  "enabledPlugins": {
    "expo@claude-plugins-official": true
  }
}

Either way, once it's installed, authenticate by running /mcp.

Now put it to work:

My Expo iOS build is failing. Investigate the cause, figure out a
solution, and make sure the solution actually works before coming
back to me.

A useful mental model: anything you can do in the Expo dashboard, there's a good chance you can do through the MCP. The build and workflow tools cover most of it.

Server tools vs. local tools

The Expo MCP splits into two kinds of tools. Server capabilities (the larger set) are installed by default and run against your dashboard. Local capabilities are a smaller set that act on your machine, and you have to opt into them with a separate install:

npx expo install expo-mcp

It lands in your dev dependencies. Local tools let the AI drive your simulator: take screenshots, tap buttons, read native and JavaScript logs, open dev tools, inspect Expo Router sitemaps. That's what makes it useful for debugging and for validating that a fix actually works rather than just compiles. To activate the local server, update your start script in package.json to the command the installer gives you, then run bun start again.

In our case the build came back green.

The root cause was a version mismatch with React Native Reanimated, which Expo Doctor had already flagged - expected version vs. found version, right there in the output:

So make sure you don't forget to run expo doctor before you waste a lot of tokens debugging - it catches these kinds of problems in seconds.

MCPs are token-heavy, so be selective

One thing to keep in mind: MCP servers are relatively token-heavy, especially when you compare them to skills. When you install one, all of its tool definitions get loaded into context up front, even if you never use them.

So only install an MCP when the project actually uses the service behind it. For example, only add the Supabase MCP if the project uses Supabase as a backend - don't install it globally.

If you want something more specialized for debugging, with access to the web, the Android emulator, and the iOS simulator all at once, look at Argent from Software Mansion. It can test autonomously across all three targets, and it's open source.

Skills vs. MCP servers: which to reach for

They solve different problems, and the difference comes down to context cost and reach.

Reach for a skill when the knowledge lives in instructions. Reach for an MCP when the answer lives in a system the agent can't see from the repo.

The ideal workflow for AI development

You can have the right skills installed and the right MCPs connected, but your AI still doesn't give you exactly what you're looking for. Why is that? There are three main reasons, and we'll dive into each one.

You're not giving it enough context

Imagine the AI as a junior developer. If you don't give them a thorough explanation of what you're looking to do, they'll form a lot of assumptions, and those assumptions are usually quite generic. Don't get me wrong, skills do help a lot. But when it comes to specific features or designs you have in mind, it's on you to communicate them. Now what if you don't even know what you want to build or how it should look?

You don't actually know what you want yet

A lot of people get discouraged by this and end up not building anything. But you're forgetting that the AI can take on any role, including an intelligent ideation buddy. For the habit tracker, instead of specifying features, I described exactly where my head was at:

I want to build a habit tracker but I'm not sure how it should look
or work, because I've tried plenty and none of them stuck. I struggled
with staying motivated and remembering to log things every day. Maybe
widgets that let me view and update the tracker automatically would
help, but I'm not sure. What do you think?

I ran that through a /co-ceo skill I built for myself, inspired by a similar one Garry Tan (CEO of Y Combinator, which backed Expo exactly ten years ago) made. If you want the AI to squeeze the doubts out of you, grill-me by Matt Pocock is a similar skill worth trying. The point underneath both: skills don't only make the AI write better code, they help you build a better product. One that solves a problem you actually have.

Notice what I left out of that prompt. Nothing about the tech stack, nothing about implementation. I didn't want to overwhelm the conversation with questions it wasn't ready to answer. Get the core idea settled first. The stack is a separate conversation, which brings us to the last failure mode.

Context bloat

Think of the AI's memory like a brain. Hand someone an overwhelming pile of information and then ask a sharp question, and you'll get a foggy answer. Same with the model. Past a certain fill level the responses get worse and each one costs more.

You can watch it happen. Tools like ccstatusline show your context window usage right in the terminal. A fresh session might sit around 5%, coming from the system prompt, your config file, and all those skill descriptions loaded up front. A full ideation session might push it to 30%. My rule of thumb: don't cross 50%. Beyond that the model starts hallucinating and stops doing its best work.

Two habits keep it under control.

First, one conversation, one outcome. Keep the ideation thread about ideation. Rename it something like "initial planning" so you can find it again. When you're ready to move to the tech stack, don't keep piling onto the same thread.

Second, branch instead of continuing. When it's time to pick the stack, branch the conversation and name the new one "tech stack." That thread carries the same context but goes its own direction, and your planning thread stays clean. You can resume the original any time. This is the same branching pattern chat interfaces have had for years, and Codex has it too, where it's called /fork instead.

So how does this look on a high level? Instead of one long conversation that blows up your context window, you keep a few short threads, each with one job: one to plan, one to spec, one to build. Anything that comes up along the way - a research question, a bug - gets its own quick branch, and you come back with just the answer.

The point here is to think of each branch as an employee who's specialized in one thing.

Where to start

You don't need the full toolkit on day one. In order of payoff:

• Add a skill. Install the Expo skills, run one with a slash command, and watch a native feature land in a single shot.
• Connect one MCP. Install the Expo MCP server so your AI can read build logs and drive your simulator. Add MCPs only for services the project actually uses.
• Watch your context. Install a status line, hold yourself under 50%, and branch your conversations so each one stays focused on a single outcome.

Do those three and the AI will start building the app you actually have in mind. There's a lot more we can get into, so come build with us: share what you make, and what you'd like to see next, in the Expo community.

Frequently asked questions

What do you need to build mobile apps with AI? Three things: skills (instruction files the agent reads on demand), an MCP server (a connection to services like your build dashboard so the agent can read logs and drive a simulator), and context discipline (keeping each conversation focused and under about half the context window). Scaffold a React Native app with create-expo-app, add skills, connect one MCP, and manage the conversation.

What is an Expo skill? An Expo skill is a folder containing a SKILL.md file that teaches an AI coding agent how to build, upgrade, or debug an Expo and React Native app. The Expo team maintains a set at expo.dev/skills, and they work with Claude Code, Cursor, and Codex.

What is the Expo MCP server? The Expo MCP server is a Model Context Protocol server that lets an AI agent read your EAS builds, workflows, logs, and crash reports, and drive a local simulator. It's free for everyone with an Expo account.

Are MCP servers expensive on context? Yes, relative to skills. An MCP server loads all of its tool definitions into the context window up front, whether or not you call them. Skills only load a short description until a task needs the full instructions. Install an MCP only for services the project actually uses.

How much of the context window should you use with an AI coding agent? A practical rule of thumb is to stay under 50%. Past that, models tend to hallucinate and each response costs more. Keep one conversation per outcome and branch new threads by task instead of piling everything into one.

How do you fix a failing Expo build with AI? Connect the Expo MCP server so the agent can read the build logs from your dashboard, then ask it to investigate and verify a fix. Run expo doctor first: it flags common problems like dependency version mismatches in seconds, before you spend tokens debugging by hand.