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.)
When I try uploading a new update for one of my macOS applications I receive the following error: (Please read to the end before assuming that I simply forgot to increment my build number - I checked similar threads)
I did my usual workflow:
Add a new version within iTunesConnect.
Increase version- & build number
Build & Archive Version for AppStore deployment.
Upload
I checked every single relevant file within my project. I increased the version- / build number everywhere. When I search the whole project for “1.22” I find no hit.
I checked the usual “wrong build version”-questions here and I did everything like stated there. May this be a bug in Xcode / Application Loader?
Edit:
Here is a screenshot taken directly from the Info.plist file from within the .pkg file:
[
As you can see, the version is 1.4 and the current build is 2. I also set this for every submodule.
Fixed it. Since it took me some time and different phrased searches to fine the solution, I will keep this thread for reference.
In Apple’s used versioning system 1.22 is greater than 1.4 since 22 > 4. That was the error.
CFBundleVersion must be higher than previous version
My first attempt was rejected and I fixed the reasons Apple gave me. Before I go through the whole archive/upload process again, should I increase the version number or build number of the app in Xcode?
You just need to increase the build number; the version number corresponds to what version your software is at.
So, you can upload "MyApp 1.0" with a Version of 1.0, and as high of a build number as you need for however many builds you've tested.
Today I got the memo from Apple as probably every other Apple developer about potentially infected Xcode installations. (https://developer.apple.com/news/?id=09222015a)
I followed the instructions and tried to validate my Xcode app using the command mentioned. (spctl --assess --verbose /Applications/Xcode.app) The program ran for a while and exited with a "/Applications/Xcode.app: a sealed resource is missing or invalid" message.
The article says "Any result other than ‘accepted’ or any source other than ‘Mac App Store’, ‘Apple System’ or ‘Apple’ indicates that the application signature is not valid for Xcode." However, I'm actually pretty sure my Xcode copy is legitimate (downloaded and updated via App Store with Gatekeeper enabled) so I thought maybe there could be another problem preventing it to validate as it should.
Do you have any ideas what this error message actually means? Do you think I need to reinstall Xcode just in case?
Thanks in advance for your help.
The false positive validation issue appears to be caused by containing previous iOS SDKs in order to be backwards compatible.
A clean install will completely wipe the SDK directories. When you run the validation test after a clean install it will pass. Once you copy previous iOS versions, which, for us, is iOS 8 for iPhone, the validation will fail.
This scenario was tested after updating to XCode 7.0.1 (7A1001) which was released earlier this afternoon.
In order to avoid a clean install, you can temporarily remove the previous SDK version from their respective location, and run the validation. Then, once the validation passes, copy the files back where they belong.
I was getting the same message "a sealed resource is missing or invalid". However i was able to rectify the issue by going into the App Store and downloading the latest version of Xcode - Version 7.0 (7A220), and this seems to have rectified the issue.
Although i did first try updating Xcode through the updates section on the App Store, but for some reason this didn't work. So i would recommend going into the App Store > Search for Xcode > Then install the latest version available to you.
Depending upon gatekeeper settings.please check gatekeeper settings to allow anywhere and revalidate Xcode.
When downloading a beta build of my app, distributed via the Testflight external tester method, the download apparently stops at about 90%. In reality the download has completed and the app is ready to go.
This is very confusing for my testers.
The only suggested fix I've found to date, is to include the app info.plist in the distribution even though Xcode complains that it is not necessary. In any case including it had no effect.
We have the same issue with our beta users. TestFlight app will stop at 90% of the filled circle. To avoid confusion between builds we have included version information in the settings page of our app to enable users to view the version number. This way they can confirm they have the latest build. The code below will create a string with the version number and build.
+(NSString *) getVersionAndBuild
{
NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:#"CFBundleShortVersionString"];
NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:(NSString *)kCFBundleVersionKey];
return [NSString stringWithFormat:#"Version %# -- Build %#", version, build];
}
I met similar problem days ago. We got answer from Apple is we need take any leading 0s out from version number. Currently, before they fix TestFlight bug, we need change version number from 1.6.02 to 1.6.2
I’d like to confirm this is still an issue as of today, as my external testers experienced exact same thing.
Everyone downloaded build 1 without problem. Then I submitted build 1.01 and testers told me installation in TestFlight app on their devices would not complete, stuck at 90%.
I had the foresight to make a spare email address and invite myself as an external tester, so I was able to verify exact same issue. However, all of us found we could just exit TestFlight and my new build had replaced the old build on the device and functioned correctly as new build.
It should have been a tip-off that my new build showed up in TestFlight as 1.1, instead of the 1.01 in my Xcode project.
Since then, I’ve run across several posts mentioning the leading zero problem. Better late than never, I actually dug into the documentation, and found this:
From App Distribution Guide: Setting the Version Number and Build String
The version number is a two-period-separated list of positive integers, as in 4.5.2. The first integer represents a major revision, the second a minor revision, and the third a maintenance release. The version number is shown in the store and that version should match the version number you enter later in iTunes Connect. For details on possible values, see CFBundleShortVersionString in Information Property List Key Reference .
The build string represents an iteration (released or unreleased) of the bundle and is also a two-period-separated list of positive integers, as in 1.2.3. For Mac apps, the user can click the version number in the About window to toggle between the version number and the build string. For details on possible values, see CFBundleVersion in Information Property List Key Reference.
Information Property List Key Reference is in documentation for Core Foundation Keys:
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.
I only used external testers for my app, so I’m not able to confirm this be the same issue for internal testers as in this post: Internal Testflight build not installing hangs at 90%