Does Expo Work With Cursor? Yes, and It Is the Default

Yes, Expo works with Cursor, and the pairing is arguably the default serious setup for AI-assisted mobile development in 2026: Cursor is an editor with an agent inside, Expo is a React Native toolchain the agent can drive entirely from the terminal and config files, and nothing in either tool knows or cares about the other in a way that could conflict. The workflow is concrete: Cursor’s agent scaffolds and edits the Expo project, Expo’s dev server hot-reloads every change onto your phone through Expo Go, and EAS handles builds and store submission from the same terminal. The setup takes minutes, the loop is fast, and the two honest gaps are the ones neither tool advertises: the agent needs your design decisions supplied, a free VP0 design being the zero-cost source, and it needs project rules written down, or its React Native output drifts web-ward. How the pairing works, the setup that makes it reliable, and the friction points with their fixes.

Why the pairing works structurally

Cursor operates on files and terminals, which is precisely the surface Expo exposes. An Expo project is a plain repository, JavaScript or TypeScript, JSON config, no IDE lock-in, so Cursor’s agent can scaffold screens, edit navigation, install packages through the Expo CLI, and read error output, the whole loop, without any integration existing between the companies. Contrast the hosted builders, where the tool owns the environment: with Cursor-plus-Expo you own a normal repo, which means version control from hour one, any CI you like, and no export day, the codebase was always yours. This is the ownership lane of the builder landscape, instantiated for mobile.

The runtime side completes the loop: the Expo dev server broadcasts changes, Expo Go on a physical iPhone or Android device renders them in seconds, and the agent’s edit becomes a visible screen faster than a simulator boots. For iOS specifically, the pairing also dissolves the hardware question, since EAS builds in the cloud and no Mac is required anywhere in the loop.

The setup that makes it reliable, in order

Minutes zero to ten: create the project with the Expo CLI’s TypeScript template, open the folder in Cursor, and start the dev server with Expo Go paired on your phone; from here every agent edit is live on the device. Minutes ten to twenty, the step most people skip and regret: write the project rules file that Cursor reads as standing instructions, stating the stack (Expo, expo-router, TypeScript), the conventions (functional components, the folder layout you want), and the constraint that matters most for mobile, native idioms only, no web-isms, because agents trained on oceans of web React will otherwise reach for divs, hovers, and pixel-perfect absolute positioning that have no business on a phone.

Minutes twenty to thirty: the design layer. Pick the free VP0 design that fits the product, and put its system into the rules file as hard constraints, exact palette values, the type scale, the 8-point spacing unit, component tone, so every screen the agent generates aims at one intentional look rather than the statistical default users recognize instantly. This is the highest-leverage half hour in the whole setup: rules plus reference turn Cursor from a fast generator of generic screens into a fast generator of your screens.

Setup step	Time	What it prevents
Expo TS template + Cursor + Expo Go	10 min	Environment friction
Project rules file (stack, conventions, no web-isms)	10 min	Web-flavored React Native
VP0 design constraints into the rules	10 min	The generic AI look
First commit + branch habit	5 min	Unreviewable agent sprawl

The working rhythm: sessions that stay on rails

The productive Cursor-Expo rhythm is the same agent discipline that works everywhere, tuned for mobile’s specifics. Card-sized tasks: one screen or one behavior per session, stated with the spec open, because mobile PRs that touch navigation, state, and three screens at once are where agent output stops being reviewable. Device-first checking: the phone in your hand after every meaningful change, not the TypeScript compiler’s silence, since layout truth on mobile lives in safe areas, keyboards, and thumb reach, none of which the editor shows. And the review split that mobile rewards: read navigation and state-management changes carefully, skim presentational tweaks, and always run the money and permissions paths yourself, unchanged from any serious AI-built product.

Two Expo-specific habits pay outsized dividends. Prefer Expo’s own modules, camera, notifications, secure store, over community packages when both exist, because the agent integrates the documented, versioned Expo module correctly far more often, and upgrades stay coherent. And keep native configuration in app.json and the config plugins rather than ejecting: the moment a project ejects to raw native folders, the agent’s reliability drops and the no-Mac story weakens, so ejection should be a named, justified decision, not a drift.

The honest friction points, with fixes

Web-ism leakage is the big one even with rules: agents intermittently produce hover states, cursor styles, window references, and div-thinking, and the fix is layered, the rules file as prevention, a per-session reminder when it recurs, and a periodic grep for the usual suspects as detection. Stale-knowledge drift is second: Expo moves fast, SDK versions deprecate APIs, and an agent’s training data always trails, so the working pattern is pasting the relevant current doc page into context when touching anything version-sensitive, upgrades especially, where the agent should execute Expo’s official upgrade guidance rather than improvise one. Third, the dev-server blind spot: Cursor’s agent does not see the running app, so it cannot know the button renders under the keyboard, which is why the device-in-hand habit is not optional, you are the agent’s eyes on the runtime. And fourth, dependency enthusiasm: agents love adding packages, each one a maintenance liability, so the rules file gets a line, prefer Expo modules, ask before adding dependencies, and the diff review enforces it.

None of the four is a reason to avoid the pairing; all four are the texture of working with it well, and they stay minor exactly as long as the rules file, the reference, and the review habit stay in force.

A first evening, minute by minute

The abstract loop lands better as a script. Minute 0: npx create-expo-app with the TypeScript template, open in Cursor, npx expo start, scan the QR with Expo Go, and the default screen is on your phone. Minutes 10 to 30: the rules file and the VP0 constraints from the setup list, plus the first commit. Minutes 30 to 75: the first real session, one card, “replace the default screen with the app’s home screen per the spec,” agent drafts, you watch the phone reshape in real time, review the diff, commit green. Minutes 75 to 90: a second card if the first ran clean, or the honest alternative, stopping while it works and writing one line about where the next session starts. The end state of evening one is the same artifact the whole pairing exists for: a screen of your actual product, in your design system, running on your physical phone, in a repo you own.

That artifact is worth naming because it is the pairing’s real pitch: not speed in the abstract, but the shortest distance between an idea and its first honest test on the device where it will live.

Where this pairing sits among the alternatives

Against Rork and the prompt-native mobile builders: Cursor-plus-Expo trades a slower first hour for an unbounded ceiling and a real repo, the correct trade once a project matters beyond validation. Against Claude Code with Expo: genuinely close, both are agents on your repo, and the practical difference is interface preference, Cursor’s editor-embedded loop versus Claude Code’s terminal-first autonomy, with teams often using both on the same codebase since the repo does not care. Against the hosted lane, Lovable and Bolt: those win the first-session race for web products and lose the mobile story, where Expo’s device loop and store pipeline are the whole game. The stack around the pairing is the standard founder stack, Supabase, RevenueCat when money arrives, EAS to ship, unchanged by the editor choice.

The honest summary of the field: for a mobile-first product you intend to own, Cursor-plus-Expo, or Claude-Code-plus-Expo, is the default that the alternatives get compared against, and the comparisons mostly measure how far each contender gets before quietly recreating this exact setup.

Key takeaways: Expo and Cursor together

Yes, they work together, structurally and well: Cursor’s agent drives Expo’s file-and-terminal surface, Expo Go puts every edit on your phone in seconds, and EAS ships from the same loop, no Mac required. Spend the first half hour where the leverage is: a rules file that names the stack and bans web-isms, and a free VP0 design’s palette, type scale, and spacing written in as constraints, which together turn fast generic output into fast intentional output. Work in card-sized, device-checked sessions, prefer Expo modules, paste current docs for version-sensitive work, and treat ejection as a decision rather than a drift. The pairing’s ceiling is the App Store and its floor is a working screen on your phone tonight.

Frequently asked questions

Does Expo work with Cursor? Yes, and the pairing is the default serious setup for AI-assisted mobile development: an Expo project is a plain TypeScript repo whose CLI, config, and error output Cursor’s agent drives directly, while Expo Go renders every edit on your physical phone in seconds and EAS builds and submits to the App Store from the same terminal, no Mac required. No integration between the companies is needed or missing; the tools meet at files and terminals, which both speak natively.

How do I set up an Expo project for Cursor? Three ten-minute steps: create the project from Expo’s TypeScript template and pair Expo Go on your phone with the dev server; write Cursor’s project rules file naming the stack (Expo, expo-router, TypeScript), your conventions, and the crucial constraint, native idioms only, no web-isms; and put a free VP0 design’s system, exact palette, type scale, 8-point spacing, into those rules as hard constraints so generated screens aim at one intentional look. Commit before the first agent session and branch per feature after.

Why does Cursor keep writing web-style code in my React Native app? Because its training data is overwhelmingly web React, so hovers, divs, cursor styles, and window references leak in whenever constraints are absent. The layered fix: a standing rules-file ban on web idioms as prevention, a session reminder when it recurs, and a periodic search for the usual suspects as detection. The leakage never fully stops, but with rules in place it drops from a pattern to an occasional diff comment, and the device-in-hand check catches what slips.

Can I build and publish an iOS app with Cursor and Expo without a Mac? Yes, end to end: development runs on any OS with Expo Go as the live preview on your iPhone, EAS Build compiles the iOS binary on cloud Macs and manages the certificates, EAS Submit uploads to App Store Connect, and review happens in the browser. The Mac requirement survives only for native Swift work and deep Xcode debugging, which staying inside Expo’s module ecosystem is precisely the strategy for avoiding. The $99 Apple developer account remains the one unavoidable cost.

Is Cursor or Claude Code better for Expo development? They are genuinely close, both agents on your own repo with the same ceiling, and the practical difference is loop preference: Cursor embeds the agent in an editor you watch, Claude Code runs terminal-first with more autonomous sweep, and the repo tolerates both, including on the same project. The choice that matters more than the tool is the discipline shared by both: rules file, design reference, card-sized sessions, device-first checks. Pick by taste, keep the discipline, and revisit the choice never.