iTunes Connect - Build Numbering

Targets iOS
1

Here’s Apple’s example of how build numbering should look in iTunes Connect:

The major version numbers are grouped, i.e. “Version 1.0” and “Version 2.0” and within each group the build numbers are listed, i.e. “Build 103”, “Build 104”, etc. According to the docs:

When I upload my Xojo-built app to iTunes Connect, the prerelease version number is the Xojo Short Version string and the build number is exactly the same. So my app version 1.0.1 has a Build called 1.0.1. My app version 1.0.2 has a build called 1.0.2, etc. This not only looks odd, but results in my test users receiving emails from Testflight that show my version as “AppName 1.0.1 (1.0.2)” instead of “AppName 1.0.0 (2)”.

Is there a way to get the right information into the Info.plist from within the Xojo IDE or do I have to manually do that?

3

@Greg O’Lone thanks for responding. I received an email with your suggestion but it’s showing deleted on the forum. So does that mean I should try that method or wait because there’s some issue?

4

You can try it. You may get dinged for the short version not conforming to apples spec. If it doesn’t work, You could modify the plist in a post build step.

5

Thanks Greg. I read on Stackoverflow that Apple seems to only care about non-confirming build numbers when you submit for review, so I’ll try this during Testflight as I think it will make more sense for our test users.

6

@Greg O’Lone I’m new to build steps. If I create a script step called “TestFlightBuild” and put that before iOS\Build with the following code:

PropertyValue("App.ShortVersion") = PropertyValue("App.BugVersion")

It doesn’t change the App.ShortVersion property. Also if I add:

print("Statecode: " + PropertyValue("App.StateCode"))
print("Shortversion: " + PropertyValue("App.ShortVersion"))

The PropertyValue of each is an empty string.

?

7

The Version fields in the iOS Inspector just don’t match up to anything in Xcode or iTunes Connect, do they? I want to increase the Build number, as per iTunes Connect requirement for a new build (i.e. a new build which isn’t increasing the version number). However, Xojo’s Major, Minor and Bug version seem to be the “Build”, which makes little sense to me.

I can’t find a relevant Feedback case - is this worth reporting? See screenshot below for example.

8

I have managed to make it work by:

  1. Ignoring Long Version altogether.

  2. Using Short Version as the over-arching version of my app. So my first release had a Short Version of “1.0” and I am now working on my second release which has a Short Version of “1.10”. This maps to “Versions” in iTunes Connect.

  3. Using Major + Minor + Bug to represent the incremental versions in “Prerelease” within iTunes Connect. So right now I’m up to 1.10.52 (Major = 1, Minor = 10 and Bug = 52).

  4. Allowing Non Release Version to increment as I build but ignoring it as it plays no part in any visible version numbering scheme.

So in iTunes Connect I currently have two “Versions”: 1.0 and 1.10 and within “Prerelease” builds I have a number of builds which use the Major + Minor + Bug versions but which are grouped by the Short Version, e.g.:

Version 1.10

  • Version 1.10.52
  • Version 1.10.51

This looks pretty good to me.

I guess in an ideal world you’d have “1.0” and “1.10” (or “1.1” if you wish) in iTunes Connect with just build numbers (e.g. “Build 52” in my current case) within each version but, while you can do that in Xcode, that doesn’t appear to be possible with the way that Xojo deals with the version numbers. I can live with it though.

9

Thanks Jason, good summary.

10

Hmmm sounds like Major Minor Sub should be landing in CFBundleShortVersion
What I’m not sure about is what apple expects in CFBundleVersion as the two sounds a heck of a lot alike

CFBundleShortVersionString (String - iOS, OS X) specifies the release version number of the bundle, which identifies a released iteration of the app. The release version number is a string comprised of three period-separated integers. The first integer represents major revisions to the app, such as revisions that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.
The value for this key differs from the value for CFBundleVersion (page 40), which identifies an iteration (released or unreleased) of the app. This key can be localized by including it in your InfoPlist.strings files.

CFBundleVersion
CFBundleVersion (String - iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.

11

Norman I remember you and I discussed this on the forum at one time and, without wanting to put words in your mouth, my recollection is that you pointed out that Apple’s docs on this might be at odds with Apple’s own practices. Perhaps it would be useful if somebody could take a look at what Xcode does and then Xojo could consider the implications of that on what happens to the version numbers in the plist?

12

That’d be useful to compare plists

This wouldn’t be the first time that Apples docs disagree or are not clear

13

This was a recent discussion where Apple’s Docs ? Apple’s Practice:

https://forum.xojo.com/26709-proper-version-number-in-info-plist/p1#p220948

14

Recent Xcode versions go along with that the original post describes, and any newly created app in Xcode does as well:

In an Xcode project you get to enter the user-visible CFBundleShortVersion (eg. 1.0.2) separately from the build number (101,102, and so on) that goes into the other CFBundleVersion.

The old beta / dev / alpha versioning scheme isn’t popular any more (as in 1.0.2.3.0).

In any case, Apple (and hopefully Launch Setvies as well, and Sparkle as well) seems to be looking onlly at CFBundleVersion, wheras the “short” version is just for user display, just like the old lonveraion and copyright.

So, what Xojo may need is to either add a new field or re-purpose the buildveraion for the bundleverssion and get rid of the alpha/beta field. Though this will certainly cause problem for existing apps / projects. And then ine also needs to consider how this works on the other platforms.

The AutoIncrementVeraion flag in Xojo could then also work better: it incerments the BundleVersion but leave the Short one alone

15

In other words: the old five-part encoding is not actually relevant any more. It was only as long as versions were still optionally encoded in a 32 bit int value.

16

This thread has proved to be invaluable to me today. Thanks to Jason for that incredibly helpful summary.

Has anyone created a Feedback case for improving the way that Xojo’s version numbering interacts with iTunes Connect? If so, I’ll add some points to it in the hope that it gets picked up on in the current release cycle so that other Xojo users don’t have to go through quite so many stages of confusion as me :wink: