Claude Code + Expo: Shipping React Native Apps to Both Stores

For a team that thinks in TypeScript, Expo removes most of the native build pain, and Claude Code removes much of the typing. Together they make a credible path from idea to both app stores without owning a Mac for every developer. This article covers the setup decisions, the EAS workflow, what over-the-air updates may and may not be used for, and the mistakes agents make in Expo projects.

Why this stack suits an agent

• One language end to end. TypeScript for UI, logic and configuration means the agent rarely switches context.
• Config instead of native code. Permissions, icons, splash screens and many native settings live in app.json or app.config.ts plus config plugins. Text files are the agent's home turf.
• Cloud builds. EAS Build compiles iOS binaries on Expo's macOS infrastructure, so a developer on Linux or Windows can still produce a signed iOS build.
• Fast feedback. Type checking, linting and Jest tests run in seconds and give the agent a clear signal.

Choose your development mode

For most agent-built apps, a development build with Continuous Native Generation (native folders generated, not committed) is the sweet spot. Write that into CLAUDE.md, together with the rule "never edit generated native folders; use config plugins".

The EAS release workflow

1. Define build profiles in eas.json: development, preview (internal distribution) and production. Claude Code can draft the file; you decide which environment variables each profile gets.
2. Set identifiers once. ios.bundleIdentifier and android.package in app config. Both are effectively permanent after the first store upload.
3. Handle credentials. Let EAS manage iOS certificates and the Android upload keystore, or upload your own. Either way, the agent should not see the secrets; it only runs commands.
4. Build. eas build --platform all --profile production produces an IPA and an AAB.
5. Submit. eas submit uploads to App Store Connect (TestFlight) and to a Google Play track. For Play, the very first upload is often easiest done manually in the Play Console.
6. Test and review. TestFlight for iOS; internal, then closed testing for Android. Many new personal Play accounts must keep at least 12 testers in a closed test for 14 days before going to production.

Each step can run in CI through EAS Workflows or your own pipeline; see CI/CD for AI-generated mobile apps.

Over-the-air updates: the rules of the road

EAS Update lets you push JavaScript and asset changes without a new store review. It is powerful and easy to misuse. A sensible policy:

• Use OTA for bug fixes, copy changes, small UI tweaks and configuration updates within existing features.
• Do not use OTA for new features that change the app's purpose, anything that would need a new privacy declaration, or adding purchase flows. Apple's guidelines restrict downloaded code that changes an app's primary functionality, and Google has comparable policies. Read the current wording before relying on OTA.
• Respect runtime versions. An update that needs a new native module will crash on old binaries. Configure runtimeVersion so incompatible updates never reach them.

Where agents trip up in Expo projects

• Installing packages with npm install instead of npx expo install, which picks versions compatible with your SDK.
• Mixing guidance from different Expo SDK versions – Expo moves quickly, and model knowledge lags. Pin the SDK version in CLAUDE.md and let the agent read the installed packages' types rather than recall APIs from memory.
• Adding permissions through libraries without usage descriptions, which leads to rejections on iOS.
• Storing tokens in AsyncStorage instead of expo-secure-store.
• Building screens that work on one screen size; ask for checks on small phones and tablets if you support them.

A CLAUDE.md section for Expo projects

Stack: Expo SDK (version pinned in package.json), Expo Router, TypeScript strict. Install packages only with npx expo install. Never edit ios/ or android/; use app config and config plugins. Done means npx tsc --noEmit, npx expo lint and npm test pass. Secrets never go into EXPO_PUBLIC_ variables, because those are bundled into the app. New permissions need a purpose string and a note in the PR. Do not run eas build, eas submit or eas update unless explicitly asked.

The last rule matters more than it looks. Builds consume your EAS quota, submissions reach real reviewers and an update reaches real users within minutes. Those commands belong to a person or to a CI job with an approval step, not to an agent experimenting in a feature branch. Adjust the commands to your setup and check the current Expo documentation for linting and routing conventions.

Store submission still needs judgment

EAS gets binaries to the stores; it does not make the app approvable. Account deletion, accurate privacy labels and Data safety answers, demo credentials for reviewers and genuine native value (guideline 4.2) remain your responsibility. Platform-specific details are in from Claude Code to the App Store and from Claude Code to Google Play; if you are weighing Flutter instead, compare with Claude Code + Flutter.

If you want the release side handled by people who do it every week, appsubmitter.io sets up the pipeline and submits signed builds in your own developer accounts, and stays with you through reviewer questions and rejections.