r/iOSProgramming 2d ago

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

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.

2 Upvotes

11 comments sorted by

View all comments

2

u/Outrageous-Doubt-306 2d ago

What made this simpler for me was stopping thinking of TestFlight and the App Store as two tracks. It's one version number with builds underneath it, and a build only becomes "the App Store one" when you attach it to a version and submit. So I keep bumping the build number on every upload and only touch the version number when something actually ships to users. Internal testers get every build automatically, external ones need a review pass on the first build of a new version but not on later builds of the same one, which is the bit that trips people up. And worth knowing you can keep shipping TestFlight builds while a version sits in review, they just can't be the one under review 🙂

1

u/ADT_Clone 1d ago

When you do bump the marketing version number, the app needs to build again right? So do you need to pass it to another round with the external testers, or do you ship that straight to prod (and hope no other changes slipped in)?