Expo in production, two years on
What holds up, what still needs native code, and how OTA updates change the way a small team releases.
Two years and four production React Native apps later, the short version is simple: Expo holds up. The escape hatches matter less often than the ecosystem suggests, while the build, update and release workflow removes work that small product teams should not have to repeat.
The biggest gain is consistency. Development builds, credentials, environment configuration and store binaries follow one documented route instead of living across several laptops. EAS Build is not magic, but it turns mobile release infrastructure into something the whole team can understand and reproduce.
Over-the-air updates change team behaviour more than any individual API. When a JavaScript or asset fix can reach users quickly, review conversations become shorter and teams are more willing to improve small details. That speed needs a release policy: runtime versions, staged rollouts and a tested rollback path keep an update from becoming a second, less visible app store.
Native modules are still where estimates go to die. Payments, specialist hardware, background behaviour and older vendor SDKs can expose gaps between a tidy JavaScript interface and the realities of iOS or Android. We budget for one meaningful native integration problem per project and test it on real devices early, before the rest of the roadmap depends on it.
Expo does not remove platform work. Permissions still need clear explanations, deep links still have edge cases, push notifications still depend on operating-system behaviour and store review still follows Apple and Google’s rules. The advantage is that the routine parts are standardised, leaving more time for the parts that are specific to the product.
It is a particularly good fit for teams shipping one product across iOS and Android with a mostly shared experience. A graphics-heavy app, unusual hardware integration or a product whose identity depends on deeply platform-specific interfaces deserves a native feasibility spike before the stack is chosen.
For the apps we have shipped, Expo has made releases calmer without closing off the native layer when it is genuinely needed. That is the useful test for production tooling: not whether it eliminates complexity, but whether it makes the remaining complexity visible, repeatable and owned by more than one person.