Before shipping a React Native plant-identification app's camera feature, why run a release build on a physical phone, and how do you run one?

## The scenario A plant-identification app lets users photograph a leaf and get a species name. The camera screen, the upload and the result screen all work in debug builds on a phone. Before release, the team needs to know the app behaves the same way **in the build users will actually get**. That means running a **release build on a physical device**, because some bugs only exist there. ## Why release-only bugs exist A release build differs from a debug build in ways that change behaviour, not just speed: - **No dev server.** The JavaScript is bundled into the app, so any code or configuration that assumed the dev server was there stops working. - **Hermes bytecode.** The bundle is precompiled to Hermes bytecode at build time rather than served as source by Metro, and it is the exact artifact users run. - **Dev-only code is gone.** `__DEV__` is false, development warnings disappear, and the Dev Menu, LogBox and React Native DevTools are disabled. - **Native optimisation.** On Android, if shrinking is enabled, classes that native modules reach through reflection can be stripped or renamed, a classic release-only crash. - **Real performance.** Debug builds are much slower on the JavaScript thread; release is the only honest measure of whether image capture and processing feel instant. ## How to run a release build on a device | Project | Android | iOS | |---|---|---| | React Native CLI | `npm run android -- --mode="release"` | In Xcode, set the scheme's Run build configuration to Release and run on the phone; `npm run ios -- --mode="Release"` builds the same configuration from the CLI | | Expo (prebuild / dev build) | `npx expo run:android --variant release` | `npx expo run:ios --configuration Release --device` | Points worth knowing: 1. On Android, the React Native docs say `--mode release` is only available once release signing is set up, and recommend uninstalling any previous version first. 2. For iOS in Xcode: **Product → Scheme → Edit Scheme**, choose the **Run** tab and set **Build Configuration** to `Release`, then run on the phone. The Dev Menu is disabled and the JavaScript is bundled locally, so the phone can be tested away from the computer. 3. Expo's docs describe `run:android --variant release` and `run:ios --configuration Release` as ways to test bugs that only show up in production builds; they are not code-signed for store submission. 4. Metro can be stopped: the docs point out that all JavaScript is bundled into the APK. ## What to check on the device For the plant-identification flow: - **Permission flow**: first launch, denial, and granting later from Settings. - **Capture**: focus and exposure in real light, portrait and landscape, and the front camera if offered. - **Processing**: time from shutter to result, and memory behaviour with full-resolution photos on a low-end Android. - **Cold start into the camera screen**, since release start-up differs from debug. - **Poor network** while uploading the photo. ## Debugging what you find Release builds are hard to inspect, since DevTools cannot attach. The usual approach: - Reproduce in a debug build first; if the bug disappears, the difference between the builds is itself the clue. - Read native logs from the device, such as Android's logcat or the iOS device console, for crashes and JavaScript exceptions. - Symbolicate any JavaScript stack with the source map from the same build. - On Android, the `debugOptimized` build type (React Native 0.82, backported to 0.81) gives near-release native performance while staying debuggable, which helps separate "slow because debug" from "slow for real". ## Making it routine A one-off release run before a big launch catches less than a habit does: - run the release build on a device for every change that touches native modules, permissions or the camera; - keep one low-end Android phone permanently available for these runs; - keep the release-run commands in the project's README so anyone on the team can do it. ## Where this sits Running release builds on devices is a pre-release check, not the store release itself: signing for distribution, uploading and store review are separate steps.