Quick answer
To build a mobile app with an AI coding agent such as Claude Code, Codex, Cursor or GitHub Copilot, start from a project that already builds and give the agent one small feature with written acceptance checks. Have it show that feature working in the installed app on iOS and Android before you review the diff. Keep signing credentials and store releases under your control.
Step 1: Pick one feature and write down how you will check it
Your cofounder posts in #mobile at 11:40 p.m.: "the agent built the whole app this weekend, take a look." The home screen looks right. You add a job note, tap Save, swipe the app away and open it again. The note is gone. The screen worked as a picture, and the feature never worked at all.
Start with a user action that touches the parts of the app you will lean on later. In a field-service app, that could be saving a job note, closing the app and finding the note again. That one action exercises storage, the network and the app lifecycle without a whole scheduling system.
Write the expected outcome before you ask for code. Decide what happens when the network is down, and whether the app may show success before the server confirms the write. Those are product decisions. Leave them open and the agent will make them for you, in a file you may never read.
A brief like this one lets you judge the result without rereading the whole chat:
Keep the first change small enough to read in one sitting. A prompt that asks for sign-in plus a subscription business in one go stacks up connected assumptions, and you won't spot the first wrong one until three more depend on it.
Step 2: Get the project building before the agent touches it
Run the unchanged project first. Install dependencies, launch the app on the iOS Simulator or an Android Emulator, and confirm it opens. If the starting project doesn't build, you can't tell an agent's mistake from a missing Xcode component or an out-of-date Android SDK.
Decide early whether you are making a website that looks like an app or an installable native app. A phone-sized browser preview proves neither that a native build works nor that the device features you need are reachable.
Pin the framework version and the package manager, and commit the lockfile. An agent that installs with npm while your CI uses pnpm will produce a dependency tree nobody else has.
Step 3: Give the agent your project rules and current docs
Write the rules down in the instructions file your agent reads. Expo's guide to AI agents names AGENTS.md at the project root as the file Claude Code, Codex and Cursor all read, and create-expo-app writes one into every new project. List the install, test and lint commands, plus the directories the agent may edit.
Spell out the decisions that are expensive to undo: where authentication lives, which store owns persisted data, and which network client the project uses. If your ios and android directories are generated from configuration, say so. Otherwise an agent will happily "fix" a generated file that disappears on the next prebuild.
Give the agent current documentation for the APIs in the task, because its memory of a library may come from an older major version. When an unfamiliar import shows up in a diff, ask which installed package provides it before you accept the change.
Keep secrets out of the instructions file and out of the app bundle. Anything bundled into a mobile app ships to every user's phone, so treat it as public. Put operations that need a private key behind your backend, and have the backend check who is calling on every request.
Step 4: Work in small changes and ask for a handoff
Ask for one feature, read the diff, and test that feature before you widen the scope. A session that ends in something you can run beats a long session that ends in a confident summary.
Ask the agent to explain every new dependency. A camera package may need a native rebuild and a permission string in the app config, and a persistence library can change how backups or migrations behave. The change is bigger than the import line.
End each change with a short handoff:
| Handoff item | What it lets you check |
|---|---|
| Changed behavior | Whether the feature matches the task |
| Files and dependencies changed | Whether the change grew past the request |
| Commands run and their results | Whether a test actually ran |
| Build number and devices used | Whether the results belong to this change |
| Remaining gaps | Whether the release still rests on something untested |
When a check fails, keep the failure. Let the agent read the logs and try a narrow fix. If it edits both the feature and the test's expected value, review those two edits together: a green test can mean the bug is fixed, or that the test stopped asking the hard question.
Commit at each working checkpoint, so the agent's repeated attempts at an environment-specific error don't get tangled up with unrelated refactors.
Design work follows the same rule. Describe the interaction you want and attach a screenshot of the current screen; "make it better" invites broad edits nobody can evaluate.
Step 5: Run the app on the platforms that matter
A Jest test can't show you how an iOS permission dialog behaves, and a simulator recording says nothing about camera quality on a physical phone. Pick each check by the failure you want to catch. Android's testing fundamentals separate a test's scope from the environment it runs in.
| Check | What it catches | What it misses |
|---|---|---|
| Static analysis and unit tests (TypeScript, ESLint, Jest) | Type errors and broken business rules | Native integration and the full user journey |
| Installed-app UI tests (Detox, Espresso, Maestro, XCUITest) | The feature failing through the real interface | Hardware the simulator or emulator lacks |
| Physical-device check | Permission prompts and device hardware behavior | Other device models your users own |
| Release build check | Problems that only appear with release configuration | Store review outcome and production reliability |
For the job-note example, run the happy path on both platforms. Then interrupt it: background the app mid-request, switch off connectivity, or reopen the app with an expired session. Use separate test accounts and a test backend.
When the feature writes data, check the data as well as the screen. A success toast doesn't prove the right account owns the saved note, so have the test read the stored record back through the test backend or an authenticated request.
Ask the agent to say plainly what it couldn't test. If it only had an Android Emulator, the iOS result is "not tested", which is exactly what the next reviewer needs to know. Keep the logs from failed runs too, even after a later run passes; intermittent failures deserve an explanation.
Step 6: Set up the release path while the app is small
Make an installable build early. You want to find the missing native dependency while the app has one feature, not after the agent has generated forty screens.
Test the release build without your laptop in the loop. A local development server can serve code and configuration that won't exist on a user's phone, so install the build and launch it with the dev server stopped.
Write down who owns the App Store Connect and Google Play Console accounts and the signing credentials. A company app shouldn't depend on one contractor's personal Apple account. Give automated jobs only the access their work needs, and keep a record of what each job produced.
Plan the backend for old app versions. Users update over days and weeks, and some never do, so a new server response must not break every phone still running last month's build.
For every release, record the build you shipped, the checks you ran and how you would recover. Recovery might mean switching off a server-controlled feature flag or shipping a replacement build.
Where Expo fits
Expo is a framework and set of cloud services for React Native apps, and React Native apps are native apps. Expo's view is that coding agents ship well on this stack, and the mechanism is the codebase. One TypeScript and React project produces both the iOS and Android apps, so one change and one handoff cover both platforms. The agent also works in a language it has seen plenty of: GitHub's Octoverse report found TypeScript became the most used language on GitHub by monthly contributors in August 2025.
Start from the create-a-project guide and keep the generated dependency versions together:
Those commands create and start a project. They don't make a production build or submit anything to a store.
Expo publishes two pieces of tooling for the agent itself. Expo Skills are instruction files that teach Claude Code, Codex, Cursor and other agents current Expo patterns; in Claude Code you install them with claude plugin install expo@claude-plugins-official. The Expo MCP Server lets an agent search the Expo docs, add packages at compatible versions with npx expo install, start and inspect EAS builds and workflows, and read TestFlight crash reports. With the expo-mcp package and a local dev server running, it can also take screenshots of your app and tap views in it, so the agent can check its own UI work on a simulator.
Move to a development build once your app needs its own native dependencies or configuration. Expo Go has a fixed native runtime, so a feature that works there can still fail in your standalone app.
EAS Build produces signed iOS and Android builds in the cloud, and EAS Workflows runs repeatable build, test and submit jobs. Give the agent the documented commands for your project and have it return the build IDs. You can use both next to an existing CI system such as GitHub Actions. EAS Update ships JavaScript and asset fixes to installed builds within the store rules; native changes still go through a new build and store review.
Limitations
The Expo MCP Server's local capabilities need SDK 54 or later, and on iOS they work only with simulators on a macOS host, according to the MCP docs. Starting an EAS build through the MCP server requires a GitHub repository connected to the project, and its documentation search tool requires a paid EAS plan. None of these tools checks whether generated code is secure or ready for store review. The people responsible for the app still need to understand how it behaves and run its services after launch.
Next step
Follow the development build introduction to get a native test environment, then build one feature against a written acceptance check before you ask the agent for the rest of the app.
Verified on 12 September 2026.