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.
This video's title is how to up the version and Build number but you are only covering the build number. Still very useful but you should rename the title or maybe I am going to be cheeky and suggest extending the video to cover the version too? :D
Appreciate the feedback! I guess the idea of what I was trying to get across is that there are two values that uniquely identify your app, and while you can (and should) automatically version your builds, you can't (and shouldn't) use automatic versioning for the actual app version. It just doesn't work with how the native app store approvals are designed. Or at least I can't think of any automated way of doing it outside of a human knowing they've published a build and now it's time to increment to a new version.
Yeah makes sense. I have found ways to version it using packages in the past. Looking at the Expo docs it looks like you can do something like eas build:version:set In case you want to set the version. I have no used it yet though so I ll will let you know when I do. 🫡 Thank you very much for the content its great!
This video's title is how to up the version and Build number but you are only covering the build number. Still very useful but you should rename the title or maybe I am going to be cheeky and suggest extending the video to cover the version too? :D