title: TestFlight In-App Updates: Version Number vs Build Number
body: <p>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.</p>
  
  <p>If I change from <code>v1.0.0 (2)</code> -> <code>v1.0.1 (1)</code>, will that allow for an In-App Update to take place? Or will I have to make the update <code>v1.0.1 (3)</code>. Having the build number as <code>3</code> 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 <code>v2.0.0 (547)</code>.</p>
  
  <p>I understand I could probably increase the build number in tandem with my version number in a nicer way (<code>v1.2.3 (123)</code>), but there are potential issues, such as <code>v1.2.34 (1234)</code> having a higher build number than <code>v1.3.0 (130)</code>.</p>
  
  <p>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.</p>
  
  <p>I'm hoping this question is okay to ask. Based on the FAQ, I should be okay to ask about <code>software tools commonly used by programmers</code>, but I have been harassed for asking about TestFlight before. </p>