15

I have an iOS app that uses semantic versioning to tag shipped builds. I'm also using Apple's TestFlight to push internal builds to the team for testing/QA.

Pushing an internal build requires uploading a build to iTunes Connect. There's no distinction between a test build and release build to iTunes Connect, and iTunes Connect does not allow overwriting previously uploaded versions. So every time I want to push a new build for internal testing, I have to bump the version number (well, the patch (X.X.X) number).

This works fine, except to our users it looks like our version numbers jump around a lot in between updates. For instance, if this is our build history:

  • v1.0.0
  • v1.0.1 (bug was found in testing)
  • v1.0.2
  • v1.1.0 (bug was found in testing)
  • v1.1.1 (bug was found in testing)
  • v1.1.2

...then the users are only seeing the bold releases, and our release history looks odd:

  • v1.0.0
  • v1.0.2
  • v1.1.2

I thought a good way to avoid this is to use beta versions, like v1.1.0-beta for the test builds, but iTunes Connect rejects any version strings that aren't X.X.X.

Is there a way to continue using TestFlight for internal testing/QA and avoid the appearance of a gap-filled version history to users?

redhotvengeance
  • 27,446
  • 10
  • 49
  • 54
  • 3
    Xcode has two separate places to put version and build number, so why don't you just leave the version number the same and edit the build number? – mhillsman Oct 15 '15 at 02:16

3 Answers3

15

I use an internal 4th number in the build version, I believe iTunes still accepts this. e.g. it might be version 1.0.0 but the build could be 1.0.0.87 indicating 87th internal build to test. You can choose to lop off the last number when displaying it in the App, but people do not usually care.

I have found this easy to understand and accepted in most places.

Build number as compared to version number is not given enough credit.

Community
  • 1
  • 1
Mitchell Currie
  • 2,769
  • 3
  • 20
  • 26
  • That works nicely! The distinction between when the version number *must* be incremented and when the build number *must* be incremented is what I was struggling with. Thanks for the clarification! – redhotvengeance Oct 15 '15 at 19:58
  • Is it legal to have 4 components? According to Apple, "Version numbers and build numbers may have up to three components separated by periods." (source: https://developer.apple.com/library/archive/technotes/tn2420/_index.html). – Vasiliy Kulakov Apr 23 '19 at 20:12
  • You can have them and query them, they will not show on the App Store however which makes them great for appending the build number. – Mitchell Currie Apr 25 '19 at 03:28
  • For iOS apps the build number does not have to be unique across versions. So for any particular version, build #'s can just be 1, 2, 3..., starting over again at 1 the next time the version is incremented (Apple calls this the version release train). – Raman Apr 16 '21 at 12:22
  • This still works in 2021. Any suggestions for Android to keep it in sync with the iOS app. The build number has to be a sequential single number in Android. – MadMac Nov 04 '21 at 01:11
5

Use the build number.

Simply sequentially increase the build number.

We just use a simple integer 523, 524, etc.

Don't change the version number for test flight because...

If you change the actual version number, you will pointlessly trigger another automated test delay for that upload! Simply increase the build number.

Fattie
  • 27,874
  • 70
  • 431
  • 719
  • Also: for iOS apps the build number does not have to be unique across versions. So for any particular version, build #'s can just be 1, 2, 3..., starting over again at 1 the next time the version is incremented (Apple calls this the version release train). – Raman Apr 16 '21 at 12:47
2

Basically the versioning has below rules.For example if existing version is v1.0.0 then the next release will be:

  • v1.0.1 For bug fixes & minor changes.
  • v1.1.0 For major changes but the App is still compatible with older versions. The user can still run the old version of app.
  • v2.0.0 For major changes but the App is NOT compatible with
    older versions. The user cannot run the old version of app.
  • v1.0.0.1(beta) For internal testing
Saurabh Bisht
  • 389
  • 1
  • 13