React Native app beta testing on iOS and Android

A React Native app ships from one JavaScript codebase but runs as two different native apps, and most beta bugs live in that gap. This guide covers how to build and distribute beta builds with Expo and EAS, what breaks differently on iOS and Android, and a task your AI beta tester can run on both builds.

Who it’s for

  • React Native and Expo developers preparing a TestFlight or Play beta
  • Teams that develop mostly on one platform and need the other checked
  • Founders who outsourced a React Native app and want an independent pass
  • Teams shipping OTA updates and native releases side by side

Updated 2026-10-25.

Why React Native apps need beta testing on both platforms

React Native lets you write one codebase and ship to iOS and Android, but the two builds are not the same app. Native navigation, safe areas, keyboards, fonts, permissions and the back button all behave differently, and most teams develop on one platform far more than the other. A beta test is where the second platform gets the attention it did not get during development.

Two categories of bugs matter here:

  • JavaScript bugs appear on both platforms the same way: a broken state update, an unhandled promise, a wrong condition. These are cheap to find on either build.
  • Platform bugs appear on only one platform: a view under the Android navigation bar, a keyboard covering an input on iOS, a shadow that renders on iOS but needs elevation on Android, a permission flow that works on iOS and crashes on Android 13 because the notification permission is new there.

Testing only the platform you develop on finds the first category and misses the second.

Builds: Expo Go, development builds and release builds

  • Expo Go is for development. It cannot be uploaded to a store and does not include your custom native modules, so never beta test in Expo Go.
  • Development builds include your native code with the dev menu enabled. Useful for internal testing, but not representative of release performance.
  • Release builds are what testers and stores get. Run eas build (or xcodebuild / gradlew in a bare project) with the production profile to produce an .ipa, .apk or .aab. Debug-only behavior like the red error box, slow JavaScript and the dev menu disappears in release, and so do some bugs, while others only show up here, like a missing production API key or a Hermes-specific crash.

Always beta test the exact release build you intend to submit, with Hermes and the New Architecture settings you ship with.

OTA updates and what they can and cannot fix

With EAS Update you can push JavaScript and asset changes to installed apps without a store release. App Center CodePush was retired, so EAS Update or a self-hosted expo-updates server are the common options now. OTA is useful during a beta for quick fixes, with two limits:

  • Native changes (new modules, permission strings, SDK upgrades) need a new store build. An OTA update that targets the wrong runtime version will be ignored or crash.
  • Both stores allow updates to interpreted code only when they do not change the app's purpose or add features that would fail review. Check the current store policy text before relying on OTA for anything beyond fixes.

Include the update path in your beta: install the previous build, receive the OTA update, and confirm the app restarts into the new bundle without losing state.

How to run a React Native beta test

  1. Produce release builds for both platforms with the same JavaScript bundle version, and note the build numbers.
  2. Run a systematic pass on each platform before inviting testers: every screen, every core flow, on a small and a large device.
  3. Fix crashes and platform blockers, rebuild, and confirm the fixes on both platforms, not just the one where the bug was found.
  4. Distribute through TestFlight and a Google Play closed track with a short brief for testers.
  5. Ask for platform, device model, OS version and build number with every report. Many React Native bugs reproduce on one platform only.
  6. Ship fixes by OTA where allowed, by new build otherwise, and re-run the core flows after each.

React Native beta testing checklist

Layout and safe areas

  • Content is inside the safe area on iPhones with a notch or Dynamic Island and on Android devices with cutouts and gesture bars.
  • Edge-to-edge on Android: nothing under the status bar or navigation bar, including modals and bottom sheets.
  • Fonts: custom fonts load on both platforms; font weights map correctly on Android (which needs separate font files per weight).
  • Shadows render on iOS and elevation renders on Android; neither clips its container.
  • Large system font sizes do not break layouts if you allow font scaling.

Keyboard and input

  • KeyboardAvoidingView or equivalent keeps the active field and submit button visible on both platforms.
  • Return key, autofill and the right keyboard types for email, number and password fields.

Navigation

  • Android system back and gesture back close modals and go back one screen without exiting the app.
  • iOS swipe back works on every pushed screen, including screens with horizontal scroll views.
  • Deep links and universal links / app links open the right screen on a cold start and when the app is already running.

Permissions

  • Notification permission on Android 13 and up, photo library access on both platforms, camera and location prompts.
  • Denying each permission leaves the app usable with a clear explanation.

Lifecycle and stability

  • Backgrounding and returning, incoming calls, low memory on an old Android device.
  • No red box or yellow warnings in the release build; JavaScript errors are caught and reported, not silent.
  • Native crashes on launch after a clean install, especially after upgrading a native dependency.

Example React Native bug report

Title: Notification permission never requested on Android 13+, reminders silently fail
Environment: Pixel 7, Android 14, build 1.8.0 (143), release build from EAS;
not reproducible on iPhone 14, iOS 17.5 (prompt appears as expected)
Severity: High (core reminder feature does not work for new Android users)

Steps to reproduce:
1. Clean install, create an account.
2. Enable "Daily reminder" in Settings.
3. Wait for the scheduled time, or trigger a test reminder from Settings.

Expected: Android asks for notification permission the first time, then
the reminder arrives.
Actual: No permission prompt is shown. Settings shows reminders as on,
but nothing arrives. The system notification setting for the app is off.

Evidence: screen recording of steps 2-3, screenshot of the system
notification settings.
Notes: iOS requests permission in the same flow. The Android code path
likely never calls the POST_NOTIFICATIONS request.

Common React Native beta bugs

  1. Content hidden under the Android navigation bar or iOS home indicator.
  2. Keyboard covering inputs on one platform only.
  3. Permission flows that work on iOS and fail on newer Android versions.
  4. Android back button exiting the app from a nested screen or modal.
  5. Fonts or icons missing on Android because of a bundling or linking issue.

Mistakes to avoid

  • Beta testing in Expo Go or a development build instead of the release build.
  • Assuming a fix on iOS is also fixed on Android.
  • Sending OTA updates that include native changes.
  • Using the newest iPhone and the newest Pixel only, when your Android users are on older mid-range devices.

Manual testing vs an AI beta tester for React Native

Human testers on their own phones catch what no automated pass can: real network conditions, camera and location use, push notifications in daily life, battery impact and the overall feel of the app. They also tell you whether the two platforms feel consistent.

An AI beta tester like betatest.ing covers the systematic pass on both builds. Upload the .ipa and the .apk or .aab from EAS; it installs them on iPhones and on Android emulators or devices, walks every screen and flow, checks safe areas, keyboards, back navigation and permission prompts, and files bug reports with steps to reproduce, severity, annotated screenshots and recordings, tagged by platform. Re-run the same task on every build so platform regressions do not slip through. It never makes real purchases, and test logins are encrypted and never shown to the AI.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Beta test my React Native app on both platforms using the uploaded builds (the .ipa on an iPhone and the .apk/.aab on Android). It is [WHAT THE APP DOES AND WHO IT IS FOR]. On each platform: install the build, go through first launch, onboarding and every permission prompt (deny one and check the app still explains what to do), sign in with the saved test login, then use each main screen and flow: [MAIN FLOWS TO COVER]. Compare the two platforms and flag anything that works on one but not the other. Check safe areas (notch, Dynamic Island, Android status and navigation bars), that the keyboard never covers the active field or submit button, that Android system back and iOS swipe back go back one step without leaving the app, and that custom fonts and icons render on both. Background the app and return. Do not make any purchases. Log each bug as a finding with the platform, steps to reproduce and an annotated screenshot, record any flow that breaks, and end with a report that scores layout, navigation, input handling and stability per platform with the top fixes.

Fill in your details

Here, or later in the chat with your tester.

  • [WHAT THE APP DOES AND WHO IT IS FOR] One sentence about the app and its users
  • [MAIN FLOWS TO COVER] The three to five flows that must work, e.g. signup, create a post, checkout

What the AI beta tester checks

  • Install and first launch of the iOS and Android release builds
  • Permission prompts on each platform, including deny
  • Safe areas, notch and Android system bars
  • Keyboard handling on every form
  • Android back button and iOS swipe back on every screen
  • Fonts, icons and platform-specific controls
  • Every main flow with the test account, on both platforms
  • Backgrounding and resuming
  • Differences between the two platforms

What you get

  • Findings tagged by platform with steps to reproduce
  • Annotated screenshots from the iPhone and the Android device
  • Recordings of flows that crash or break
  • A side-by-side report with per-platform scores and the top fixes

How to run it with betatest.ing

  1. Build release binaries with EAS or your native toolchain and add the app as a project in betatest.ing.
  2. Upload the .ipa and the .apk or .aab, and add a test login if the app needs an account.
  3. Send the React Native beta test task; the tester runs both builds.
  4. Fix the platform-specific findings, rebuild, and ask for a re-test before inviting external testers.

Tips

  • Test the release build with Hermes and the same settings you submit, never Expo Go.
  • Keep an older mid-range Android device in your test matrix; emulators and new Pixels hide performance problems.
  • Include the OTA update path in the beta: old build, update applied, app restarts cleanly.
  • Ask testers for the platform and build number on every report.

React Native app beta testing: FAQ

Can I beta test a React Native app in Expo Go?

No. Expo Go is a development client that does not include your custom native modules and cannot be shipped to a store. Beta test the release build produced by EAS Build or your native toolchain, which is what your users will install.

Do I need to test both iOS and Android if the code is shared?

Yes. The JavaScript is shared, but navigation, safe areas, keyboards, permissions, fonts and the back button all behave differently. Most React Native beta bugs are platform-specific and only appear on one build.

Can I fix beta bugs with an OTA update?

JavaScript and asset fixes can go out through EAS Update or a self-hosted expo-updates server, as long as the runtime version matches and the update does not include native changes. Native fixes need a new store build. Check the stores' current policy text on updates to interpreted code before relying on OTA for new features.

Can an AI beta tester test my React Native app?

Yes. Upload the .ipa and the .apk or .aab from your release build. It installs them on a real iPhone and on Android emulators or devices, walks each flow, and files bug reports tagged by platform with screenshots and recordings. It cannot install from TestFlight or an invite-only Play track.

Why does my app crash in the release build but not in development?

Common causes are a production API key or environment variable that is missing, a Hermes-specific issue, minification breaking code that relied on function names, or a native module that is linked only in debug. Always beta test the release build to catch these.

How do I distribute React Native beta builds?

Use TestFlight for iOS and a Google Play internal or closed testing track for Android. EAS Submit can upload to both. For very early builds, an .apk can be shared directly with your team.

What should a React Native bug report include?

The platform, device model, OS version, build number, whether the bug reproduces on the other platform, steps to reproduce, expected and actual behavior, and a screenshot or recording. See our bug report guide for a full template.

Will it test in-app purchases?

Only with StoreKit sandbox accounts or Play license testers, and it never completes a real purchase.

Related beta testing guides

  • Mobile app beta testing — Mobile apps reach testers through store testing tracks, run on hardware you do not control, and get interrupted constantly. This guide covers how to distribute a mobile beta, what to test that is specific to phones, and how an AI beta tester fits alongside your human testers.
  • Flutter app beta testing — Flutter draws its own UI, so a Flutter app looks the same on iOS and Android until it touches the platform: plugins, permissions, navigation gestures, text scaling and the renderer. This guide explains what to beta test in a Flutter app, how to distribute release builds, and gives you a task your AI beta tester can run on both builds.
  • iOS app beta testing — TestFlight is how almost every iOS app gets into beta testers' hands before the App Store. This guide explains how TestFlight testing works, what to check on iPhone that differs from Android, and how to run an AI beta test on a real iPhone from an uploaded .ipa build.
  • Android app beta testing — Android beta testing means getting a test build onto many different phones and finding what breaks before the public release. Here is how Google Play testing tracks work, what to test that is specific to Android, and a task your AI beta tester can run from your uploaded build or Play link.
  • Mobile app crash testing — Crashes are the bugs users forgive least and the ones store algorithms punish most. This guide explains what makes mobile apps crash, how to trigger those conditions on purpose before launch, how to read Android and iOS crash data, and a stability task your AI beta tester can run on every build.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in by product