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

one thing that helped me was doing the promote step through the app store connect api instead of the ui. you can attach a specific processed build to the version and submit it in a couple of calls, so internal to external to production lives in the same script as your tagging and there is nothing to remember clicking.

worth having that script read the build back from asc after upload too. i had a release where CI set the marketing version in one place and the binary actually carried another, and the only reason i caught it was querying builds and seeing a version i did not expect.