If you're targeting both stores with a small team, native-per-platform is usually the wrong tradeoff. Expo's tooling has gotten good enough that you write TypeScript once, EAS Build compiles native bundles, and OTA updates ship JS-only fixes without re-submitting. Pair with Cursor + Claude and the loop is faster than either native track.
Expo· Build infra + OTA updatesCross-platform tradeoffs are real (animations, deep platform integrations). Use Claude up front to mark which features genuinely need native vs which can ride on Expo's SDK.
Cursor is great at TypeScript. React Native ecosystems are well-trained-on, so suggestions are reliable. Composer covers cross-file refactors when you change a navigation pattern or auth provider.
Expo Router for navigation, EAS Build for managed native compiling, EAS Update for shipping JS fixes without store review, EAS Submit for one-command store uploads. The infra you'd otherwise rebuild every project.
Projects maintain context over months of work, with a coordinator agent that plans work and delegates to subagents running in parallel. Projects can watch Slack channels or run on schedules to take action without being prompted, keeping shared context across all agents involved.
Projects is a new feature that maintains context over months of work and delegates tasks to thousands of subagents. A coordinator agent plans the work and delegates to implementation agents that run in parallel. Projects can watch Slack channels, follow PRs, or run on a schedule to take action automatically without prompting.
Projects enables managing feature development, migrations, and full apps with a coordinator agent that plans work, delegates to subagents, and maintains context over months. The coordinator runs agents in parallel and can watch Slack channels or run on schedules to automatically pick up work without explicit prompting.
Expo now includes built-in PostHog integration that sets up analytics, session replay, and error tracking in one command. Events are automatically tagged with the corresponding EAS update version for better correlation between app behavior and deployments.
Some apps shouldn't be Expo (heavy AR, custom video pipelines, deep iOS WidgetKit). Use Claude to audit upfront.
Audit whether the idea below is a good fit for Expo + React Native, or whether it should be native (Swift / Kotlin) per platform.
Idea:
"""
{{1-line description + the 5 most-important features}}
"""
Output:
1. **Verdict**: Expo / Native iOS / Native Android / Both native — and a 1-sentence "why".
2. **The 3 features that drive the verdict** — and which side they push toward.
3. **Mitigations** — if Expo, are there config-plugins or community modules that close the native gap? Be specific.
4. **Costs of the wrong call** — what does this app look like in 12 months if I pick the other path?
Be honest. The answer "this should be native" is allowed.`npx create-expo-app`, then Cursor's Composer to scaffold tabs + screens. The Expo Router file-based routing makes the screen layout legible in one folder.
Expo Go on your phone for the inner loop. EAS Build only when you need a real native build (signing, native modules, store submission).
`eas build --profile production --platform all` builds both iOS and Android binaries in the cloud. ~15 min the first time, faster after caching.
`eas submit` uploads to TestFlight + Play Console in one command. `eas update` ships JS fixes after launch without re-submitting (within Apple's policy boundary).
Could not have justified two native codebases. Expo + Cursor put the team at parity with native-only competitors on screens-shipped-per-week. The only feature they had to drop was a custom haptic pattern that wasn't in expo-haptics; they shipped without it and added a config plugin in v2.
If your app's core is AR, custom audio, or watchOS / Wear OS companions, Expo will fight you. The 'fitness audit' step exists to catch this before you've written 10k lines.
OTA updates are the killer Expo feature, but they live inside Apple's policy boundary (no major feature changes via JS). Plan from day one which features are JS-only and which need a native build + submission.
When a native module isn't in expo-* or doesn't have a config plugin, the temptation is to eject to a bare workflow. Don't, unless you're sure. Expo's prebuild + config plugins almost always cover it.
What changed in AI tools and the stacks that ship. One email a week.