This argument is usually fought by people who last touched Expo in 2019, when "ejecting" was a one-way door and half the native modules you needed were unavailable. That version of Expo is gone. The advice built on it should go too.
What actually changed
Expo's config plugins and prebuild mean you no longer choose between "managed" and "bare" as a permanent identity. You write native configuration as code, expo prebuild generates the ios/ and android/ directories, and you can regenerate or commit them. The one-way door became a revolving one.
That single change invalidates most of the arguments still being repeated in comment threads.
The honest decision rule
Use Expo unless you have a specific, named reason not to.
That is not enthusiasm, it is arithmetic. On a recent build the Expo toolchain removed roughly a week of setup I would otherwise have paid for by hand:
- OTA updates without standing up your own CodePush replacement
- Builds on EAS without maintaining a macOS runner
- Push notifications without writing the APNs/FCM plumbing twice
- A dev client that other people on the project can install without Xcode
A week is a real number on a fixed-price project, and none of it is work a client can see.
The specific reasons not to
There are genuine ones. If any of these describe your project, reach for the CLI:
- A native SDK with no config plugin, and no appetite to write one. Some payment, DRM and telematics SDKs still ship install instructions that assume you own the Xcode project. Writing a plugin is possible — I have done it — but budget a day, not an hour.
- You need a build step Expo's prebuild would overwrite. If someone has hand-edited the Podfile in ways that cannot be expressed as a plugin, prebuild will fight you every time it runs.
- Binary size is a hard requirement. Expo's runtime is not enormous, but "not enormous" is not the same as "zero", and some markets genuinely care about a 20MB download.
Notice what is not on that list: "it is a serious app". Seriousness is not a build tool.
What I do now
Every new project starts as Expo with prebuild and committed native directories. That gives the ergonomics of managed and an escape hatch that is already open — if I need to touch native code, it is already there, and I have not had to migrate anything.
The migration I did in the other direction, CLI to Expo, took two days and mostly consisted of deleting things.
The part nobody mentions
The build tool is not what will make your app late. Design churn, a backend that changes shape halfway through, and App Store review are what make apps late. I have never once missed a date because of the choice discussed in this post.
If you are picking a stack for something real and want a second opinion on it, tell me what you are building — I would rather talk you out of a bad fit than take the work.