Why We Use Expo for Every React Native Project

When clients ask us to build a mobile app, one of the first decisions we make is how to set up the React Native project. The ecosystem has evolved dramatically over the past few years, and Expo has evolved with it. Here’s our current thinking.

The Old Reputation Doesn’t Apply Anymore

Expo used to mean accepting significant limitations: no custom native modules, slow OTA updates, limited background processing, and a managed build environment that occasionally surprised you.

That Expo is gone. The current Expo — with the bare workflow, Expo Modules API, and EAS Build — gives you a first-class native development experience with dramatically less configuration overhead. We’ve shipped HIPAA-compliant healthcare apps, apps with complex Bluetooth integrations, and apps using custom native camera processing — all on Expo.

Why Expo, Every Time

EAS Build

Expo Application Services Build replaced the gnarly world of manually configuring Xcode build settings, provisioning profiles, and Android keystore management. EAS handles all of it, including over-the-air updates, staged rollouts, and build caching.

The time we save on build infrastructure on every project justifies the EAS cost many times over.

Expo Router

File-based routing for React Native apps is a revelation. Coming from web development, we’re used to Next.js-style routing. Expo Router brings that mental model to mobile with deep linking, typed routes, and shared routes between web and native when building universal apps.

// app/(tabs)/profile.tsx
// That's your /profile route. That's it.
export default function ProfileScreen() {
  return <Profile />;
}

Expo Modules API

When we do need native functionality, the Expo Modules API makes writing native modules dramatically simpler than the old react-native link era. Modules are written in Swift/Kotlin with a clean API surface exposed to JavaScript. We’ve written custom modules for Bluetooth LE, biometric auth flows, and device health integrations — none required deep native expertise.

Development Experience

npx expo start and you’re running. Hot reloading just works. The Expo Go app handles most development and testing needs without a full native build. When you need a device-specific native module, EAS Build handles the development client.

Compare this to a bare React Native setup where a fresh install might require Xcode configuration, Android SDK path setup, and thirty minutes of debugging before you see a running app.

When We Use the Bare Workflow

We use the bare workflow on every project — “managed” means accepting constraints we consistently don’t want. The bare workflow gives us full android/ and ios/ directories to modify while retaining the Expo tooling.

The key question isn’t managed vs. bare. It’s Expo vs. plain React Native. Expo wins every time.

Real Project: MediTrack

The MediTrack patient app (featured in our portfolio) is a good example of what Expo enables:

• Biometric authentication: Custom Expo module wrapping LocalAuthentication
• Offline data: WatermelonDB with SQLite via op-sqlite
• Push notifications: Expo Notifications with APNs/FCM
• Background sync: Expo BackgroundFetch for periodic data sync
• OTA updates: EAS Update for hotfixes without App Store review

All of this in a codebase that a small team can maintain and iterate on quickly.

The TypeScript + Expo Combination

Expo Router ships with full TypeScript support including typed route parameters. Combined with Zod validation on API responses, you get end-to-end type safety from the server to the screen.

// Typed route params just work
const { patientId } = useLocalSearchParams<{ patientId: string }>();

Conclusion

The mobile development landscape has consolidated around Expo for good reason. The tooling is excellent, the ecosystem is rich, and the overhead of maintaining raw native build configuration is now mostly optional.

If you’re starting a React Native project in 2024, start with Expo. Add native modules where you need them. Use EAS Build and EAS Update. Ship faster.