iOS Build version Doesnt Match IDE

Ive been trying to update an iOS app.
It is the usual pain: minimum XCode version has changed etc etc etc

But one thing I seem stuck on right now is a simple version number.
The App Store has a build 196
I changed the version , saved, closed, opened, checked
Then I build and Transporter tells me the version is 1§4, despite the IDE showing this:

I can find no way to make the version change to 197, 198 or 199
Does anyone know why it seems stuck on 194 when 194 doesnt appear anywhere in the IDE?

set non release to 200 and try again (leave “Version” empty)

Also make sure you don’t have any plist entries added yourself (custom Info.plist)

And make sure to remove old versions from Transporter. I’ve had problems like this when old versions were still there.

Keep in mind that the App Store requires that the version numbers change in an upward version with each build you send them.

Whoa wait. Version vs Non-release version?

Yeah, Xojo renamed these fields recently. Version is the “human readable version string” whereas the version fields are what the App Store needs,.

Trust me, I have changed every number visible on that tab, but the packaging list that is generated (by Xojo) says 194 every time I build.
I’m currently updating XCode and Transporter, then I will try again.

Here’s what I suggest you try:

Apple really is picky (at times) about version numbers changing “in the right way”. I used to run into this every year with Xojo’s XDC app when it was refreshed.

NOTE: sorry, Stage Code should have been Final in that screenshot.

Changed to 1.9.8 and it changed what Transporter ‘saw’
It says uploading 1.9.8 then complains that this is less than version 196 which is ‘out there’

But it also says I am using SDK14.4 instead of 15 , which is ‘included in Xcode 13’
Since I am on XCode 14 (later), I am now very confused.

(At least it isn’t moaning about certificates and profiles so far!)

Asset validation failed (90062)
This bundle is invalid. The value for key CFBundleShortVersionString [1.9.8] in the Info.plist file must contain a higher version than that of the previously approved version [196].

SDK Version Issue. This app was built with the iOS 14.4 SDK. All iOS apps submitted to the App Store must be built with the iOS 15 SDK or later, included in Xcode 13 or later.

All seems OK there, but xcodebuild is out of date, yet I just updated Xcode 20 minutes ago…

jefftullin@JeffTulComputer ~ % /usr/bin/xcodebuild -version
Xcode 14.2
Build version 14C18

Ok, so let’s go over some things.

The fact that you had 196 in that field before seems to mean that Apple thinks it was version 196.0.0. That’s a bummer and the only way to remedy that is to continue making larger version numbers. That said, I’m going to suggest that you align the major, minor and bug numbers with that field.

The SDK version has nothing to do with Xcode. Xojo itself has its own “version” of the SDK that they have to rebuild each year so that everything will work properly. Make sure.l you are using the latest version of Xojo that you can.

What version of Xojo are you using?

I think I have a handle on the version number… using 198.0.5 will probably do the trick.
I currently have 2021 R1 and R3 installed for iOS work, but I do have a current licence.

Xcode tools looks like the final (?) rock to crack

jefftullin@JeffTulComputer ~ % /usr/bin/xcodebuild -version
Xcode 14.2
Build version 14C18

You’re going to need at least something after the fall of 2022 to get SDK 15. It’s a constant slog to keep up with xojo versions for iOS development, but without these machinations, declares don’t work.

1 Like

Ive downloaded the latest build. Looks like the problem still lies with the Xcode command tools, which are version 14 from July last year
Despite being ‘inside’ Xcode, they didn’t get changed when I upgraded Xcode today.
Frustrating. Im missing something important, clearly.

So Ive deleted the developer folder and Im reinstalling Xcode Command tools.

But they may be coming by carrier slug…

Don’t forget to go into the Xcode preferences and set the tools version.

If Apple cares about the value of the string “Version”, the interface should add a bit more of cleverness trying to guess some inconsistencies on the “version” x “major”+“minor”… and ask something like “version seems inconsistent? Are you sure?” [Fix for me] [Continue]

Do I need to install Ventura as well as Xcode and a new Xojo?
Im on Monterey, Ive reinstalled command line tools , deleted Xcode, reinstalled Xcode 14 and still don’t have the option to select iOS 15 SDK, despite the simulators showing iOS 16.2

All the Apple docs say that SDK 15 is available from Xcode 13

Under Xojo 2022, I can build for Store, and it uploads via Transporter - but I cant run in debug as it fails to codesign with a message about detritus.

I appreciate this all sounds like a rant, but it seems I have to go through this carp or similar, every 6 months. This is no way to run a railroad. :frowning:

OK: The results are in…

Xcode shows 14.2 in the tools section because it is Xcode 14.2
The SDK covers up to 16.2 but it says nothing about that.

Xojo 2021.x when it compiles for the App Store, uses SDK 14.x ,even though a later SDK exists, and Xojo has no preference setting for the SDK version.

Xojo 2022 when it compiles for the App Store, uses SDK 15(?, or at least something after 14), because Transporter doesn’t complain.

Xojo 2021 R1 can run a debug version in the Simulator.
Xojo 2021 R3 gives an error about signing/detritus and won’t run in debug.
Neither will Xojo 2022.
Same source code, same Xcode, same simulators.

I have no problem running in Xojo 2022 here on my M1 MBP.

Thats encouraging.
Something code-signy in Xojo changed by the looks of things… doesn’t work for me.

In my experience, the detritus error in iOS comes from build scripts that change the app after the Sign step. Make sure all of the things that change the plist and your CopyFiles steps are in the right place.

You could (but shouldn’t have to) add a step that runs xattr -cr <path to app> just before signing. The IDE does do that (at least it did just before I left) and it should fix this error.

Just curious though… when that error is shown, have you tried looking at the whole error to see if there are any details about what might be wrong?