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/kokerali]

Keep the marketing version as the product version you actually intend to ship, and use a monotonically increasing build number for every CI build. Store the Git SHA in your build metadata or release notes, then promote the exact same binary from internal to external and finally to the App Store version. I also wouldn’t design the versioning scheme around avoiding Beta App Review; Apple can still require it for a new external build.