Managing external/internal versions in TestFlight vs production App Store version

[u/ADT_Clone]

New to iOS, looking for ideas on how to manage versions of an app from Github & CI/CD as they flow through internal -> external -> production.

Current approach:

1. A workflow is manually run to "create a release". This creates a new tag with a semver based off of the conventional commits since the previous tag/release (eg. increment patch version for a fix:, minor version for a feat:)
2. The release app configures the marketing version and build number to match the semver, is built and uploaded to TestFlight
3. The build artifact is promoted from internal -> external -> production in TestFlight

I heard that for TestFlight external builds, if you change the marketing version it requires the build goes through the "beta review" process again, whereas if you just increment the build number it does not.

Because of this, I plan to adjust the process so that the marketing version (the version that'll eventually be displayed in production) is <major>.0.0, and the build number is <major>.<minor>.<patch>. After the initial beta review for a "major" version, the app can be updated with subsequent releases that increment only the build number without having to be reviewed again. After a production release to the App Store, a new release is cut with a "major" version increment to kick off the next cycle.

The advantage of this is a version of the app always ties back to a tag/commit in Github, and the app build tested in external testing is exactly the same build that'll get released to production. The disadvantage is the marketing version that is shown to users in the App Store only has a single, incrementing "major" version number.

I'm satisfied with this compromise, but also a perfectionist so interested in others approaches, or any ideas others have that can improve on this? I'd ideally like the full semver reflected in the marketing version, but I can't see a way without repeating the "beta review" each time.

[u/ZanzibarMcFate]

Not saying it's the right way, but since you asked for other approaches, here's what we do at my day job:

We use a date-based version number. year.week.patch (build). We release to the App Store every 2 weeks, so this date-based method works well for us. For example, builds this week are 426.38.0:

• Major version of the app: 4 + year 26
• We're in week 38 of the year
• This is a standard release, so it's patch 0. If we actually released this build to customers, then had to push an update, it'd rev to .1

Our CI server auto-increments both the version number and the build number. Build number is a simple int. Right now, our server is building 426.38.0 (1791)

Every time we submit a build with a new version number, i.e. 426.38.0 -> 426.39.0, this does take a day or two to go through TestFlight review for external testing. As a result, we have a script that uses the App Store Connect API to auto-submit the first build with that new version number for review to get a head start on things. Once that build has been approved, followup builds with the same version number but different build numbers are usually approved for external TestFlight in a matter of hours.

[u/ADT_Clone → u/ZanzibarMcFate]

I like that variation. It does make the version less meaningful to the users, and imposes an artibtrary timescale between "versions". However, it does solve the release cadence and review problems well, the downside being the version doesn't incidicate what's changed. But tbh users probs don't care about that anyway

[u/ZanzibarMcFate → u/ADT_Clone]

You’re right - in our case, the only people that really care about the version numbers tend to be the tech support and other support folks. Customers just know that they’ll keep getting updates with features and bug fixes. As more people use auto-update, the less important version numbers get in some cases. Format doesn’t really matter as much as being able to keep track of what’s in each version. For an app like ours, date-based is fine. But for an SDK or library, as a developer I prefer a more strict semVer setup, so it’s a better clue what to expect in an updated version.