Most of my project increase the build number fine using Xcode UI, but there is one that stopped doing it and I am struggling to remember to change it in the info.plist so I was hoping there was a way to fix it.
Changing the version number as shown in the below image from the general tab of the target changes it for all of my dozens of apps, except one that only recently stopped, which I wouldn't be surprised if the reason was that I accidentally changed a setting or something:
I archive this specific project and even though the version number is 1.5, it still shows 1.4 unless I change it in the info.plist, as shown below (after I changed to 1.5):
Is there a way to fix this? Its frustrating when I look in the organized when I'm ready to submit the app and see the wrong version number when I just waited 15 min to build the archive for the app.
I did just recently upgrade to Xcode 14, but I've submitted 4 apps this week and this is the only 1 that this is happening for.
Thank you!
I uploaded a build using the Xcode beta, forgetting that you can't submit builds compiled with beta versions. So I updated to the release version of Xcode via the App Store.
With the Xcode beta, App Store Connect was accurately reflecting the build number (4.8.1). Now with the release version, Connect shows a build number of 5. I tried incrementing in Xcode to 4.8.2, and now Connect showed a build number of 6.
Has this happened to anyone else?
It's not a bug, it's a (new) feature.
Your build number must increment on every new build. A lot of people, including you, don't know that. So now, during the build submission, your build number is validated, and it is automatically incremented if necessary.
So that's what happened: your build number was corrected to 5; then you tried to lower it, which is illegal, and submitted again, and it was corrected to 6, which is right.
Note that the build number should be just a number, not a dotted version string.
Also, you can reset the build number to 1 if you up the user facing version string.
I experienced the same issue with XCode 13 and finally found the cause: during the process of uploading the archive, you are presented with a dialog that includes a "Manage Version and Build Number" checkbox. By default, it is ticked (i.e. checked). Untick this box to prevent the build number from being auto-managed by Apple.
This is definitely a bug.
The release notes just say the build number must be a valid build number and the current documentation for CFBundleVersion says it is a machine-readable string composed of one to three period-separated integers.
I was using xcrun altool --upload-app to upload my app and after switching to Xcode 13 when uploading my app with version 4.7.123 it automatically "corrected" it to 5.
I am now using xcrun altool --upload-package along with --bundle-version to set the build number which works except that I can no longer upload any version 4.7 apps because the currently uploaded version is 5.
I rejected a binary i had which was 1.0 (1.0).
The status went into Rejected by developer.
I went to upload a new binary and ran into this issue, i then saw that i needed to increment my build.
I increased both the app version and build to 1.1, this was a mistake.
I got some error about the app version not matching, understood.
Then i tried app version 1.0 and many different build numbers.
1.1, 1.0.1, 1.2, 1.3, 1.0.3..nothing works.
I keep getting this error. There is only one build listed on itunes connect (1.0)
I tried submitting with no binary and it says i need one.
I even tried changing the app version to 1.1 in itunes connected and then uploading
1.1 (1.0) and that fails as well with the same duplicate issue.
Anyone ever have this issue?
The workaround of changing the build number is working for me, with the following context:
the app version status is "Prepare for submission"
the new version number is well saved in iTunesConnect (pressing the save button on version page in iTunesConnect)
the CFBundleShortVersionString is matching the version number in iTunesConnect (e.g. "1.2")
the CFBundleVersion in the Info.plist is incremented (e.g. 1.2.1)
In this way, several build are associated to the iTunesConnect version.
Here is how it looks like in iTunesConnect (1.2 is the short version number, 1.2 and 1.2.1 are the bundle versions):
I was trying for hours with no luck, after waiting a few more hours i got a reply from apple support asking for more info.
When i went to replicate the issue again for screenshots i decided to use a build number of 2.0, i was hoping maybe it wanted the major version to be higher.
This worked!
Everywhere online that i read said that 1.0 to 1.1 would work fine...or 1.0.0 to 1.0.1.
I, for some reason, had to go from 1.0 to 2.0.
Or there is always the possibility that waiting a few more hours did something.
Solved this issue by incrementing build version by 1 instead of sub-version. i.e. 1.0 to 2.0 instead of 1.0 to 1.1
I experienced this also, just increase the build number fixed it for me. I changed the build version to 1.0.1 and it worked. This can be found in the 'General' Tab in Xcode. Make sure you archive and validate again before submitting to App Store.
You need not to change the version number ,just change the Build number. But you should know that the Build number must be higher than last version you had uploaded. For example, your version number is 2.6.8 and Build number is 2.6.8 then you can change the Build number to 2.6.9. If you change the Build number to 2.6.8.0 it will occur a error say that the Build number(2.6.8.0) must be higher than the exist one(2.6.8) . So the key point is Build number.
#Jayprakash Dubey
#Tenaciousd93
Tried many different build numbers myself. The only option that worked for me was to give a 4 figures build number : 1.1.0.1 (1.1 being my app version number on iTunes Connect).
Hope it helps!
I guess, since Apple has integrated test flight into itunesconnect, there is a difference between version and Build (which is the wording they use in project-settings->target->generalScreen) and in info.plist its equivalent is "Bundle Version String short" and "Bundle Version". Here the wording has never made real sense to me.
I have gotten the error with version 2.2 and build 2.2. I changed it to version 2.2 and build 1 (because it was my first upload) and it worked.
For certain reason, Apple provided the build field on the General Tab in Xcode.
I have also encountered this issue and as much as you do, I am getting the same error over and over again even if I was changing the version numbers.
What is suppose to be done here is to update the build number only even using the same version number.
In my case, I have an App version 0.0.1, every time I upload a binary I need to change the build number eg:
Upload build 0.0.0 - Reject Binary and
Upload build 0.0.1 - Reject Binary and
Upload build 0.0.2
I tried ApplicationLoader 2.9.1, it's working for me.
ApplicationLoader 2.9.1 can download from itunes connect.
I've had this problem before and have solved it like you have, by upping my build number every time. It has always worked.
Now however, I am completely stuck. I have just added the Today Extension to my app, and now when I try to upload it always comes back with a 4238, no matter what version / build combination I put in. It's crazy, been at it for 2 hours now.
I'm wondering if there is any way certain build settings could make the uploader think there are 2 binaries?
I have a separate distribution profile for the main app and the extension, I also have 'Build Active Architectures Only' set to NO. That is all I can think of that would mess this up.
Any thoughts?
My issue was that the build number that I was updating in the General tab of Xcode wasn't changing the bundle version in the app's plist - so the uploader thought I was uploading the same build every time no matter what build number I was using. Once I changed the bundle version in the plist, everything worked fine.
I solved same problem...I uploaded a version 1.01 and build 1.1 then I decided to reject this compilation. I Changed on i-tunes version to 1.1 and tried to upload new version 1.1 build 1.1 and I got error. Then I change on xcode to build 1.2 and upload ok.
In my case I had to make build numer higher that last build number I uploaded. I had on iTunes Connect app with build number 3, then rewrote app from scratch and tried to upload new app with build number 1 I got same error, after changing to build number 4 it worked fine.
Check if you have used the run script:
if the answer is yes, then you have to submit your changes to your git server, then the script will increase your build version number automatically!
Solved this problem by Modifying the Build Number under General -> Identity in the Target build of the Xcode project. Afterwards go to the Product menu, select Clean and Build your app.
From Build : 1
To Build : 1.2
Finally, repeat the app submission process by running Product -> Archive and follow the screen prompts.
I have uploaded the app, but for missing screenshots for 3.5", I got the same error.
And could not upload again from xcode.
(So I make an ipa file, in xcode organizer and export as ipa).
But when I press the upload build in the itunesconnect then it take the old uploaded file (give me an option to choose).
And then after saving this, I got the option for submit for review.
(If you go to the pre release tab in itunesconnect, you can see the previously uploaded app.)
I downloaded this Xcode project(version 1.0 as in contents.xcworkspacedata) from here
When I try to open it, got this error:
Failed to load project at '.../Lesson31_OSXCocoa/Lesson31_OSXCocoa.pbproj', incompatible project version.
How do I open project version 1.0 with xcode 4.2?
You're better off trying to find a newer tutorial, or just studying the code as-is, without expecting to build and run it.
Judging by the modification dates, this code is almost ten years old. Even if you can get a modern version of XCode to open it, there's no reason to think that the headers, libraries, etc., that it needs to compile and run will still be compatible. Moreover, ten years is a long time in software terms. While some of the content might still be applicable, it certainly won't be anywhere near the cutting edge (which itself won't be new by the time you've mastered it).
All that said, if you're really intent on working with that project file in XCode 4.2, the best way is probably to convert it the same way a continuously developed project would have: XCode by XCode.
You can download older versions of XCode from Apple here (requires free Apple developer account).
Some older version will be able to import that file and update it to a newer format.
Assuming you don't stop at that point and use that version of XCode, you can repeat the process with the updated project file and ever-newer versions of XCode until you've arrived at version 4.2.
Relatively easy to make a new project and add the appropriate files to it. Took less than 10 minutes (had to update the code in a few places). Note that I didn't spend much time cleaning up this old code - quite a few deprecated warnings. But it runs and works. I have Xcode 4.3.2 installed but hopefully you'll be able to open it with 4.2. Here's a link to it: Lesson31.zip
Note that the process for doing this (so you can do it for any others), is to create a new Mac OS X Cocoa Application project, add the files (except main.m) from the old project to the new project, and then add necessary libraries to fix link errors (OpenGL Framework). If there's a nib then you can open that in Xcode and copy the window with view and controller out of that project and paste them into the .xib file created with the new project. Then fix compiler warnings/errors as necessary (add a few (char*) coerces, remove reference to std::ios::nocreate which doesn't seem to be available, etc).
I am updating an application (not developed by me) that uses three20. I was successful in getting it to build and run on Xcode 4.3.1 which is great :o) I am now concerned about memory leaks (no arc in the app yet) and want to run the app through the profiler. When I try to do this (Product --> Profile) I get Three20 build errors again. Specifically "Three20Core/private/TTExtensionInfoPrivate.h"file not found and a Shell Script Invocation Error in the three20/src/scripts/Protect.command: line 31
line 31 in the Protect.command was added in to get the app built and running on this version of Xcode - it reads: cd ${PREFIX}${PUBLIC_HEADERS_FOLDER_PATH}
I take it that the profiler must use a different Header search path or Build Location?
Has anyone dealt with this issue before or have an idea for solving?
Fixed the problem above - the TTExtensionInfoPrivate.h file was in the Three20Core directory and there was no private subdirectory. Removed "private/" from the two #import Three20Core/private/TTExtensionInfoPrivate.h commands (these were in TTExtensionInfo.m and TTExtensionLoader.m) and was able to build and run my app through the profiler.
An easier approach it to add $(BUILD_DIR)/three20 to Paths.xcconfig under common/Configurations
HEADER_SEARCH_PATHS = $(STDLIB_HEADERS) $(BUILD_DIR)/three20 $(CONFIGURATION_BUILD_DIR)/../three20