Set the build number to increment automatically and learn when to increment version numbers.
While you’re developing your app, when you submit an app with a specific version + version code to the App or Play Store, you cannot submit another app with the same values.
The best practice is to set the build number to increment automatically.
The version number can be incremented manually after each store release.
📖 Docs
[00:00] Every mobile app build is uniquely defined by 2 values, an app version starting from 1.0.0 and a build number or a version code starting from 1. You can see the app version on test flight here and the build version here. When you're developing your app, when you submit an app with a specific version and version [00:20] code to your app or play store, you cannot submit another app with the same values. Notice that the apps in test flight are grouped by the version number. As you're working on 1.0.0 of your app, every time you want to upload a new version to test flight or to Google Play to share with your testers, you'll need [00:40] to increment this build value to from 1 to 2 to 3 etcetera. Then once you create a production build and release 1.0.0 to your users, you can no longer upload builds using this value and you'll have to increment, for example, to 1.0.1. If you ignore this and try to submit an app with the same values, you will see this error in your [00:59] EAS submit logs saying that the current build number is already being used and you need to either set the build number or auto increment it. Your app JSON is where the version number lives. You'd usually increment this manually only after you submitted a release build to the stores. For the build number, open EAS JSON, and under [01:19] the production build profile, set auto increment to true. This will ensure that the build version is automatically incremented. Now run EIS build to rebuild both apps. You can see that due to us setting auto increment to true, the Android version code is getting bumped from 1 to 2 and same for iOS.