Expo managed workflow vs bare React Native

WHAT THIS TESTS The interviewer wants to see practical decision-making about React Native tooling, not memorized marketing. They are checking whether you understand the real constraints each path imposes on a team.

A GOOD ANSWER COVERS Start with what Expo managed gives you: zero native setup, a fast start, over-the-air updates, EAS Build for cloud iOS and Android binaries, and a large set of vetted native APIs like camera and notifications. Then explain bare React Native: full access to the native projects, the ability to add any native module or SDK, and direct control over build configuration. Note that the gap has narrowed because Expo supports custom native code through config plugins, prebuild, and a custom dev client, so you rarely have to choose all or nothing. The deciding factors are your team's native expertise, whether a required SDK has no Expo support, build and signing infrastructure, app size, and how much you value OTA updates.

COMMON WRONG ANSWERS Claiming Expo cannot use any custom native code is outdated. Treating ejecting as a one-way disaster ignores prebuild. Assuming bare is always more professional or performant is wrong; Expo apps ship to large production audiences.

LIKELY FOLLOW-UPS What is a config plugin and when would you write one? What does EAS Build and EAS Update do? How does the Expo dev client differ from Expo Go?

ONE CONCRETE EXAMPLE A small team shipping a content app with standard needs like push, camera, and auth picks managed Expo for speed and OTA fixes. A team integrating a proprietary Bluetooth medical SDK with no Expo plugin and custom signing requirements leans bare, or uses Expo prebuild with a config plugin to wrap that SDK while keeping EAS benefits.