Development build vs production build in Expo

What each build is

A development build is your app compiled with the expo-dev-client library. It contains your app's native code and libraries but loads JavaScript from a development server, so changes appear on the phone instantly while you work, with debugging menus available. A production build is compiled in release mode with the JavaScript bundled inside, optimised and signed for store distribution. Expo's default eas.json also includes a preview profile, which builds release code for internal distribution, so testers can install a realistic version without going through a store.

How the profiles differ in practice

Each profile in eas.json sets options that EAS Build reads. distribution: internal makes the build installable by direct link: on Android as an APK, on iPhone with ad hoc provisioning, where EAS generates a provisioning profile listing the allowed device ids, so only registered devices can install it. The production profile defaults to store distribution: an Android App Bundle for Google Play and an iPhone build signed for App Store Connect, which TestFlight can then share with testers. The same project can produce all three, and teams often add their own profiles for staging environments.

When to use which

Use a development build while writing and debugging the app day to day. Use a preview or internal build when someone else needs to try it on a real phone: the owner, staff or a few customers. Use a production build when the app is ready for review, and for TestFlight and Google Play testing tracks, since those take store builds. A common mistake is sending testers a development build, which needs a running development server and shows debug tools.

Common mistakes

Expecting an internal iPhone build to install on a device that was not registered when it was built. Sending a production Android App Bundle to someone to install directly, when only an APK installs outside the store. Forgetting that development builds are slower than release builds, then judging performance on them. Changing native libraries and expecting an older development build to load the new code. Using different bundle ids per profile without meaning to, which makes the stores see separate apps. And building for production before checking the version numbers.

Where it shows up in OneCraft

OneCraft runs Expo builds for Android or iPhone on paid plans: a test build, with a QR install on Android or an Expo page on iPhone, or a store build, at 5 credits each. Builds run on OneCraft's Expo organisation unless the owner connects their own token, and iPhone builds need the owner's Apple key. OneCraft does not submit apps to the stores: the owner submits from their own accounts with eas submit, at Apple's 99 USD a year and Google Play's 25 USD once.

Questions people ask