TestFlight and Beta App Review - Can't Set Build Number with Xojo

Targets iOS
1

Is anybody using TestFlight to test with internal and external users? I’ve been testing with internal users and just started testing with external users a couple days ago. I submitted a build for Beta App Review and it passed so I shipped it to external users. But then I needed to release a new build to fix some bugs and that’s where I’ve come unstuck.

In the past I have been incrementing the bug version number for each release. So my version number is made up of Major.Minor.Bug. My current version is, for example, 1.0.30. This is the version that I shipped to external users and so that’s the one that was approved via Beta App Review.

In order to upload a new version, I had to give it a new version number. So this version is 1.0.31. However because the version number is different, it needs to be re-submitted for Beta App Review before I can ship it to external users. I thought there was supposed to be an option to specify that the version contains no significant changes and thus circumvent or at least speed up the Beta App Review process but I can’t find that option. This is from Apple’s docs:

I am not prompted about whether I have made any significant changes. Is anybody with experience using TestFlight able to shed any light on this?

2

OK so I’ve been doing some more research and it seems the issue is that I need to upload a binary with the same Major.Minor.Bug version number but with a different Build number in order for TestFlight not to require an additional Beta App Review. The issue, though, is setting this up within Xojo.

I need to keep the “Bundle versions string, short” the same in the info.plist. That part is easy, because it comes from the Short Version in the Shared Build Settings within Xojo. The problem is adding the Build number or “Bundle version”. As I previously reported I can’t work out how to have Xojo insert the build number into the plist as part of building the app and doing so after the fact is not an option when you need Xojo to create an App Store build with an .ipa file.

I know I can include an info.plist as part of my app’s files, and I use that for some MapKit settings, but Xojo over-rides or ignores the “Bundle version” property in my included info.plist and instead writes the same string that it writes into “Bundle versions string, short”.

I need a solution for this otherwise TestFlight beta testing with Xojo is unworkable.

3

A post build step which is after the compile & link but BEFORE building an ipa etc

the defaults command should be able to over write it

4

I don’t understand what you mean by “the defaults command” Norman?

5

Which key is it your trying to set ?
The exact name would help since there are a few which might be “Bundle Version”

6

defaults - is a command line command that lets you manipulate plists
you could execute it as part of a post build step to set what ever key it is your referring to

7

Ah I see whats going on
In an iOS project
CFBundleVersion will be set to whatever major . minor . bug is
And if you try to set it in your own plist the build will gleefully ignore it and set it to major.minor.bug

The CFBundleShortVersionString will be set to what ever you set the short version string to in the Shared settings

Basically you want to overwrite CFBundleVersion with increasing single digits and probably set the CFBundleShortVersionString to major.minor.bug.
Correct ?

8

Great
Apples Info Plist reference says

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.

Hence why we set it to major.minor.bug when you compile
Additionally it says

CFBundleShortVersionString
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 36), which identifies an iteration (released or unreleased) of the app. This key can be localized by including it in your InfoPlist.strings files.
So they look like they should be set much the same

BUT when I go look at a default app in Xcode for iOS it has a single digit for CFBundleVersion and a 2 digit string for the short version string
ARG ! APPLE !!!
What they write & what they do are so often far far far apart

9

Yep, that’s it Norman. So TestFlight requires that the CFBundleVersionShortVersionString be identical (but doesn’t seem to care what it is) so as not to trigger an additional Beta App Review while CFBundleVersion needs to change in order to upload the binary via Application Loader otherwise Application Loader rejects the upload because it says the version already exists.

I am unable to meet this criteria using Xojo settings, or a build script or an included info.plist file.

10

[quote=189354:@Norman Palardy]Basically you want to overwrite CFBundleVersion with increasing single digits and probably set the CFBundleShortVersionString to major.minor.bug.
Correct ?[/quote]

Yep. Is there a way to do this now?

(BTW I don’t mind if I have to manually do something between building and uploading or before building, etc. I just need to be able to ship updates to my beta testers without triggering an additional Beta App Review)

11

[quote=189356:@Jason Tait]Yep, that’s it Norman. So TestFlight requires that the CFBundleVersionShortVersionString be identical (but doesn’t seem to care what it is) so as not to trigger an additional Beta App Review while CFBundleVersion needs to change in order to upload the binary via Application Loader otherwise Application Loader rejects the upload because it says the version already exists.

I am unable to meet this criteria using Xojo settings, or a build script or an included info.plist file.[/quote]
Sure you can
Set “Short Version” in the IDE under Build Setting > Shared
That lands in CFBundleShortVersionString

Set Major Minor Bug version to increasing numbers
That goes into CFBundleVersion as major.minor.bug

Now IF the reviewer says CFBundlerVersion has to be a single digit increasing like 1 then 2 then 3 etc THAT will require intervention
And you can use either the defaults command to write to the just built apps plist (you’d have to poke around in terminal and there may even be something on the forums about how to use this to do what you need)

The command will be something like

defaults write path to your just built apps plist 'CFBundleVersion' ‘new value’

12

This should work, but IMHO the results aren’t the best. I was hoping to have a versioning system in this format:

Major.Minor.Bug (Build)

But this will mean I have this format:

1.00 (Major.Minor.Bug)

or, using my current numbers:

1.00 (1.00.30)

That’s not ideal and, in any case, is going to trigger a further review because of the version number change. But I’ll give it a try.

13

Like I said what I see in the docs vs what I see them doing in Xcode are two different things

So i’m not sure what will make it such that you don’t have to resubmit for beta review BUT I would continue to post your findings & experiences here for us all to follow and maybe we need to change how we generate the plist for iOS
That’s certainly possible

14 
<key>CFBundleShortVersionString</key>
	<string>1.0</string>
<key>CFBundleSignature</key>
	<string>????</string>
<key>CFBundleVersion</key>
	<string>1.0.1</string>

right out of a Plist created by XCODE for a Swift app that was accepted by Apple on first try

CFBundleShortVersionString came from Identity->Version
CFBundleVersion came from Identity->Build

perhaps it is the leading zeros you have???

15

Thanks Dave. The only problem now with the version number is that I wanted it to look different to the way it looks, but it isn’t stopping the app approval. I’ve decided to go with Norman’s suggestion. So I’ve changed my CFBundleShortVersionString to “1.0” and Xojo is filling in the CFBundleVersion from Major.Minor.Bug. This produces the same result as you’re seeing from your Swift app. I’ve resubmitted the app for beta review and, given that it was previously approved, it’s likely just a waiting game now. After the next approval I shouldn’t need to submit it for additional reviews during my beta now that I’ve changed my versioning system.

16

Brand new iOS master detail
No code even added
Just created the project

	<key>CFBundleShortVersionString</key>
	<string>1.0</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleVersion</key>
	<string>1</string>

Get the exact sane if I tell it to use Swift or Obj-C
Fun Fun Fun

17

Question: I found that using “defaults” to manipulate plist files that go into an OSX app did not work well as I then also had to fix the owner or filemode afterwards. The proper way, I found, was to use PlistBuddy instead, which comes with Xcode and is used by Apple’s own build scripts as well.
Did you have no such issues with the defaults cmd?

18

Never had to use defaults or plistbuddy to modify a plist for an iOS app so it was only a “best guess” that it would work

“Something that can alter the key in the plist generated” is really what was meant