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.
Cross-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.
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.