Expo

Expo is a framework and cloud service for React Native. The framework gives you a managed native project you do not edit; the service (EAS) builds, signs, submits, and updates it.

The decision that shapes everything else

Expo's workflows are a spectrum, not a switch, and the common failure is choosing before understanding what you give up.

| Workflow | You edit native code? | ios/ and android/ in Git? | | --- | --- | --- | | Managed with config plugins | No | No — generated by prebuild | | Prebuild checked in | Yes | Yes |

The managed workflow is not "Expo without native modules" — config plugins exist precisely so a native dependency can be added without owning the native project. Reach for checked-in native directories only when a change genuinely cannot be expressed as a plugin. Going back is harder than going forward: once ios/ and android/ are committed, prebuild will overwrite hand edits, and regenerating becomes a merge rather than a build step.

What to verify rather than recall

Expo's release cadence is fast and SDK-versioned, so remembered values age badly.

• SDK version compatibility. Each Expo SDK pins a React Native version and a supported package range. A package version that worked on one SDK frequently does not resolve on the next.
• Config plugin options and app.json / app.config.js keys, which move between SDK releases.
• EAS Build image and channel configuration in eas.json.

Check these against the mirrored corpus under references/vendor/ or the release notes rather than asserting a version.

References

• Expo documentation
• SDK reference
• Config plugins
• Development builds
• EAS Build
• EAS Update
• Expo Router
• Changelog and release notes