This is our workflow and I think this is the same for many organizations: Setup Expo updates with: runtimeVersion: { policy: 'appVersion', }, Create an appVersion 1.0.0, build number (10001) Generate a TestFlight (channel production), test Bug reported on a native library (cannot use eas update), fix the bug, build number (10002) Generate a new TestFlight, test At this point, TestFlight version 1.0.0 (build 10001) is not testable anymore, it crashes on app launch, even if we do not use "eas update" to deploy the fix, which is quite strange imo. We would like to set runtimeVersion based on build number instead of app version to prevent this problem. One more problem about the current solution is that if we push the version 1.0.0 (build 10002) in production. We work on next version 1.0.1 (10101) but, we forget to update appVersion in app.config, we let 1.0.0 and generate a EAS Build on channel production. All of users will have a crash on app launch. I red the documentation ( https://docs.expo.dev/eas-update/runtime-versions/ ) and you wrote: "If this error does occur, then you can republish a previous known-good update, then ask users to delete the app and reinstall it.". Asking thousands of user to delete app and reinstall it is not possible. You also mentioned that you are working on a solution to prevent the crash but in the meantime we also would like to run many same app version on TestFlight and I think, allow setting runtimeVersion with build number can be a solution.