Menu
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.0v1.0.1 (bug was found in testing)v1.0.2v1.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.0v1.0.2v1.1.2I 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?
294
To add Internal testers: Navigate back to your app in My Apps, select the TestFlight tab and click Internal Testing on the left-hand side; Now click the (+) sign next to the header Internal Testers; Check the box next to any eligible users who have not already been invited and click Add.
Install TestFlight on the iOS device that you'll use for testing. Open your email invitation or tap the public link on your iOS device. Tap View in TestFlight or Start Testing. If you're testing an app that's for Apple Watch only, tap Install or Update from the Apps list.
1(2) you can upload 1.0. 1(1) as well as 1.0. 0(5). There is no restriction for uploading lower version or lower build.
After beta testing your final build, submit it to App Review, then offer it on the App Store. If you used TestFlight to distribute a beta version, and entered the additional information required by App Store for a release, just submit the last build that appears in App Store Connect to App Review.
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.
50
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
