TestFlight In-App Updates: Version Number vs Build Number
auto-update, ios, release, testflight
Solution
Since the old TestFlight is now replaced by iTC TestFlight, I've decided to manage my version and build numbers in a logical way. Over time, I found what works best is to break down the version numbers like so:
A version number is simply the history of your product in a numerical form. It is typically broken down as [major].[minor].[patch].[build] where the build number is optional (especially in iOS). An application is considered alpha or beta while the major number is less than 1 and is released at 1.0.0.0.
Major
The major number signifies a massive change in your application. Incrementing this number is appropriate when a user will need to change the way they use or think about your application. When this number updates, deprecated functionality is expected to be dropped and the application is in a clean state. Minor and patch numbers should be reset to 0 and build should be reset to 0 or 1.
- Complete UI overhaul
- Dropped previous functionality - not deprecated
- Significant featureset added - big enough to change the use of your application, otherwise use sequential minor updates
Minor
The minor number signifies a noticeable change in your application. When this number updates, some functionality may become deprecated, staging for being dropped in future major updates. The patch number should be reset to 0 and build set to 0 or 1.
- Added a feature
- Introduced new UI
- After a significant amount of patches that all tie into a superset
Patch
The patch number signifies small changes in your application. When this number updates, the application isn't necessarily released (assuming the major is at least 1) and functionality is not deprecated.
- The build number is set to 0 or 1.
- Bug fixes
- New feature
- Non user-facing changes
Build
The build number signifies the developer's build index. This number should always and only increment with each build that each developer makes. If developers are working on the same branch, the build number should increment with commits instead of builds.
Problem
What is the logic behind the version number and build number in TestFlight's In-App Updates? TF declares that the build number must be greater in order for the In-App Update to pop up and take place, but I always reset the build number when I increment/increase the version number. If I change from `v1.0.0 (2)` -> `v1.0.1 (1)`, will that allow for an In-App Update to take place? Or will I have to make the update `v1.0.1 (3)`. Having the build number as `3` doesn't sit well with my OCD, as I appreciate having sensible numbers in my build histories. I would really hate to see something along the lines of `v2.0.0 (547)`. I understand I could probably increase the build number in tandem with my version number in a nicer way (`v1.2.3 (123)`), but there are potential issues, such as `v1.2.34 (1234)` having a higher build number than `v1.3.0 (130)`. I am releasing to clients, so I am uncomfortable testing this and I'm using a company developer account, so building random test applications probably won't look great, either. Hopefully someone may have an easy answer to my inquiry and I've overthought all of this. I'm hoping this question is okay to ask. Based on the FAQ, I should be okay to ask about `software tools commonly used by programmers`, but I have been harassed for asking about TestFlight before.