Skip to content
useffect.sh
Book 30 min with a senior
Scale · from bare React Native to Expo

Migrating to Expo: prebuild, config plugins, EAS

Hand-maintained ios and android folders, Podfile patches, builds that only pass on one Mac. Expo generates the native projects from your configuration. We run the migration in your repo, step by step, without rewriting the app.

Short answer

The useffect.sh Expo migration moves an existing bare React Native app onto Expo: the SDK, prebuild, config plugins, development builds and, if you want them, EAS for builds, store submission and over-the-air updates. It is for teams that maintain their iOS and Android projects by hand, whose builds only pass on one machine, or who want to ship JavaScript fixes without going back through store review. It starts with a five-day diagnosis: inventory of native modifications, dependencies and the release pipeline. Then one or more senior engineers migrate inside your repo, through PRs reviewed in your own process, with a demo every week: install the SDK and Expo Modules, then turn each native modification into a config plugin until the native folders can be deleted. You get an app whose native projects regenerate with npx expo prebuild, and a release runbook your team can follow.

of diagnosis
5 days
apps published on the stores
100+
a week, in your repo
1 demo

01

When to call us

  • The ios and android folders are edited by hand.

    Nobody knows anymore which lines of the Podfile, build.gradle or AppDelegate were added, or why. Every upgrade replays the same diff blind.

  • The build only passes on one machine.

    One specific Mac, one specific Xcode, a signing profile nobody dares to regenerate. Release builds depend on a single person.

  • A JS fix is waiting on store review.

    A typo or a logic bug goes through a full review again, or several if it gets rejected. An over-the-air update would push the fix without a new binary.

  • An Expo library you can’t install.

    expo-camera, expo-notifications or a third-party config plugin would solve the problem, but the project has no Expo SDK.

  • A new developer takes a week to get a build.

    Ruby, CocoaPods, JDK, Android SDK, certificates. With a development build, they install the app and connect to Metro.

  • Several apps, native config duplicated.

    White-label or per-country variants: the native configuration is copied from one project to the next. Prebuild and config plugins describe it once.

02

How it runs

  1. 1 / Days 1–5

    Migration diagnosis

    Diff between your native folders and the reference Expo template, inventory of libraries, in-house native modules and release steps. A written diagnosis, three pages max, with the path and the hard spots.

  2. 2 / Weeks 1–2

    Install Expo without breaking anything

    The Expo SDK and Expo Modules go into the existing project, native folders kept. A development build goes out to the whole team, Metro unchanged.

  3. 3 / Weeks 2–N

    Move each native change into a config plugin

    Permissions, URL schemes, entitlements, third-party SDKs, in-house modules: every manual edit becomes a config plugin or an Expo Module. When npx expo prebuild --clean produces an identical build, the native folders leave the repo.

  4. 4 / Last weeks

    Release and handover

    EAS Build, Submit and Update configured if you adopt them, runtime version set, build profiles per environment. Release runbook and handover to your team.

03

What you get

  • Written diagnosis with the migration path
  • App on the Expo SDK, native projects generated by prebuild
  • Config plugins for every native modification
  • In-house native modules ported to Expo Modules
  • Development builds for the whole team
  • EAS Build, Submit and Update pipeline, if adopted
  • Release runbook

04

Comparable missions

05

Common questions

How much does an Expo migration cost?

It depends on how many native modifications have to become config plugins, how many in-house modules have to be ported, and how many apps or targets there are. The five-day diagnosis is there to cost it on evidence, before the first PR.

Do we have to rewrite the app?

No. The React Native code stays the same. What changes is how the native projects are produced: described in the Expo config and config plugins instead of maintained by hand. Your screens, your navigation and your stores don’t move.

Do we lose control over native code?

No. Prebuild generates the projects, and you can open them in Xcode or Android Studio at any time. Anything config plugins don’t cover gets written in Swift or Kotlin inside an Expo Module. And you can keep your native folders in the repo if you prefer.

Is EAS mandatory?

No. Expo works with your current CI: prebuild, then build locally or on your runners. EAS adds cloud builds, store submission and over-the-air updates. We set it up if you choose it.

What can we ship over the air?

JavaScript, styles and assets. Not native code, not a new permission, not an SDK change: those go through a new binary. The runtime version makes sure an update only reaches compatible builds.

How long does the migration take?

Five days for the diagnosis. The migration itself depends on how many native modifications there are to convert and how many in-house modules to port: that is what the diagnosis costs. The app stays shippable throughout.

See also

Terms on this page

Updated October 26, 2026

Your native projects can be regenerated.

30 minutes with a senior to estimate the path to Expo. Free, reply within 48 hours.

Book 30 minutesBack to home