My client is trying to install a build. Everytime, it hangs at 90%. Sometimes they leave it -- still hanging -- and check the app and see the version numbers as incremented.
This time though, they've left it running there for 5 minutes and still the version hasn't updated.
They removed the app and tried to install again and it's not installing, just hanging. How do I fix this?
I had this same issue and worked with Apple for literally a month going back and forth with there engineers. In my case it was my build number had a 0 after a . which for some reason they have a bug that considers that an 'old' version of your app.
Maybe you are having the same issue:
OK = Build #: 2015.6.29
Not OK = Build #: 2015.06.29
I know it sounds ridiculous but that was the fix for my issue. Not also Apple made mention that I shouldn't start my version number with 0 either, but I can not confirm that.
I ran into this same problem today but only used external testers, so while I suspect the following should apply to internal testers, I can’t confirm. Here is what I found in the documentation:
From App Distribution Guide: Setting the Version Number and Build String
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.
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.
We got into this situation two different ways. It started off by submitting a build, call it 0.9.1. Everyone was happy and could install.
We then submitted 0.9.2, somehow the provisioning profile became invalid after submitting. The result was that folks would get to 90% then be told that it could not be installed.
After we discovered that the profile had gone invalid, we turned off the switch for TestFlight testing. Users that continued to follow the email link would be presented with 0.9.2 even though the build wasn't available and would get the same 90% experience. For these users, we could instruct them to tap the "Close" at the top left where they would return to the list of apps in TestFlight and there they could tap on 0.9.1 and be good to go.
After this I invited some new testers. All of the new tester receive invites for 0.9.2 even though it is disabled, and there doesn't seem to be a way to help them. We are just going to have to submit a new build.
Related
Traditionally, I used to manage build and version numbers with Apple's agvtool and/or build scripts. However, when uploading an archive to App Store Connect, I noticed that there is now a new option:
Manage Version and Build Number
Archive's build number does not meet App Store Connect requirements. This will change the version and build number of all content in your app to 1.0 (2).
I was expecting this to automatically update my target's Version and Build numbers. Instead, I see that it doesn't update version numbers at all; and, although it updates the build number, it only does so in the archive, so my Xcode project shows a stale value.
How do I get this new feature to update my target's Version and Build numbers?
For reference, this is what a new project in Xcode 14 (SwiftUI Interface) looks like...
The Info.plist is no longer auto-created. Instead, the target's Info tab shows Bundle version string (short) (CFBundleShortVersionString) and Bundle version (CFBundleVersion) hard-coded to the values ${MARKETING_VERSION} and ${CURRENT_PROJECT_VERSION}, respectively:
I say "hard-coded" because no matter what I try (deleting them, updating them, or redefining a value like CFBundleShortVersionString in an Info.plist) the two settings are reset to look like the screenshot above, upon navigating back to the Info tab.
Also note that MARKETING_VERSION defaults to 1.0 (which is odd since the CFBundleShortVersionString documentation clearly states it must be 3 integers); while CURRENT_PROJECT_VERSION defaults to 1.
Attempting to change the bundle values in the General tab simply changes the backing property's value (e.g. MARKETING_VERSION for "Version").
Unless someone has a better answer, this is what I've been able to glean/guess so far...
The "Distribute apps in Xcode with cloud signing" WWDC 2021 video mentions it only increments build numbers in the archive:
New in Xcode 13, if Xcode detects I am distributing with a build number that has already been used on App Store Connect, or that is not incrementing, it will offer to increment the build number in the archive to one that is valid. [emphasis added]
This answer quotes the following from the Xcode release notes, which again suggests it only increments build numbers, and only updates the archive:
When uploading an app to App Store Connect, the distribution assistant in Xcode detects whether your app has a valid build number (CFBundleVersion). If your app has an invalid number (like one that was used previously, or precedes your current build number), the distribution assistant provides an option to automatically increment it to a valid number. In addition, the distribution assistant ensures that the build numbers of all embedded content in your app (such as app extensions, App Clips, or watchOS apps) are in sync with your app. Note that this doesn’t modify your source code or your archive; Xcode updates the build number in a staged copy of your app before packaging and uploading it to App Store Connect. (59826409) [emphasis added]
The "Manage Version and Build Number" feature is poorly named. While Build Numbers are incremented, Version Numbers are only updated in embedded frameworks, to keep them in sync with the main app. This is often undesirable, and probably why people are looking to permanently disable it.
In summary:
If you don't have embedded frameworks, then using this feature to increment build numbers is fine. Keep in mind that your target's build numbers won't be updated though.
Whenever you need to increment the version number, you need to manually increment it.
I have an iOS app that uses semantic versioning to tag shipped builds. I'm also using Apple's TestFlight to push internal builds to the team for testing/QA.
Pushing an internal build requires uploading a build to iTunes Connect. There's no distinction between a test build and release build to iTunes Connect, and iTunes Connect does not allow overwriting previously uploaded versions. So every time I want to push a new build for internal testing, I have to bump the version number (well, the patch (X.X.X) number).
This works fine, except to our users it looks like our version numbers jump around a lot in between updates. For instance, if this is our build history:
v1.0.0
v1.0.1 (bug was found in testing)
v1.0.2
v1.1.0 (bug was found in testing)
v1.1.1 (bug was found in testing)
v1.1.2
...then the users are only seeing the bold releases, and our release history looks odd:
v1.0.0
v1.0.2
v1.1.2
I thought a good way to avoid this is to use beta versions, like v1.1.0-beta for the test builds, but iTunes Connect rejects any version strings that aren't X.X.X.
Is there a way to continue using TestFlight for internal testing/QA and avoid the appearance of a gap-filled version history to users?
I use an internal 4th number in the build version, I believe iTunes still accepts this.
e.g. it might be version 1.0.0 but the build could be 1.0.0.87 indicating 87th internal build to test. You can choose to lop off the last number when displaying it in the App, but people do not usually care.
I have found this easy to understand and accepted in most places.
Build number as compared to version number is not given enough credit.
Use the build number.
Simply sequentially increase the build number.
We just use a simple integer 523, 524, etc.
Don't change the version number for test flight because...
If you change the actual version number, you will pointlessly trigger another automated test delay for that upload! Simply increase the build number.
Basically the versioning has below rules.For example if existing version is v1.0.0 then the next release will be:
v1.0.1 For bug fixes & minor changes.
v1.1.0 For major changes but the App is still compatible with
older versions. The user can still run the old version of app.
v2.0.0 For major changes but the App is NOT compatible with
older versions. The user cannot run the old version of app.
v1.0.0.1(beta) For internal testing
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.)
According to bullet point 3 of the accepted answer here:
CFBundleVersion in the Info.plist Upload Error
Apple is supposed to be comparing the "CFBundleVersion" (i.e. "Bundle
version" not the "Bundle versions string, short")
However in this posting:
Difference between Xcode version (CFBundleShortVersionString) and build (CFBundleVersion)
It says Version maps to CFBundleShortVersionString and Build maps to CFBundleVersion.
Therefore that means when you submit a new version of an app to the app store, the comparison is being done on the build and not on the version that you see in the XCode summary page.
This seems the wrong way round to me - especially given the quote from the Apple documentation:
CFBundleShortVersionString represents a release version, whereas
CFBundleVersion represents any build, released or not.
This means when submitting a new version of an app you need to be concerned with the build number, not the release number, which to me seems odd. Its more odd because according to this:
What's the difference between "version number" in itunes connect, "bundle version", "bundle version string" in xcode?
The CFBundleShortVersionString MUST be the same as in iTunesConnect. Then why are Apple checking the CFBundleVersion and not the CFBundleVersionShortVersionString?
I have submitted an app where both the version and build were 1.0, now I want to submit a new version and have bumped both to 1.0.1, will this cause any issues when submitted?
The reports from users seem to be inconsistent. Also, the SO answers are more than 2 years old.
The section about "configuring your app" in Apple's App Distribution Guide says this:
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 can contain a mix of characters and numbers, as in
12E123. 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.
For iOS apps, update the build string whenever you distribute a new
build of your app for testing. iTunes will recognize that the build
string changed and properly sync the new iOS App Store Package to the
device. For how to configure your app for testing, read “Beta Testing
Your iOS App.”
This indicates that for the App Store what matters is CFBundleShortVersionString and it should match the value in iTunes connect. And that changes to CFBundleVersion are considered when differentiating between builds for testing.
However, this somehow contradicts what "Information Property List Key Reference" says about 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.
It isn't the first time or the last that Apple's docs have contradicting information.
Personally, I'd go with the App Distribution Guide guidelines but setting the same version number for both values seem to comply with both documentations, so you should be ok.
For my Mac OSX app, I am using a dotted version in CFBundleShortVersionString and a running integer (that corresponds to my SCM revision number) in CFBundleVersion. Submitting updates like that for years and never had a problem
Each time I attempt to publish an update to an app I receive this automated email response moments later:
We have discovered one or more issues with your recent delivery for "App Name".
Your delivery was successful, but you may wish to correct the following issues in your next delivery:
Version Mismatch - Neither CFBundleVersion ['9.1'] nor CFBundleShortVersionString ['9.1'] in the Info.plist match the version of the app set in iTunes Connect ['2.41'].
I understand why the message is being generated but I would like to resolve the issue without having to compromise the version # by making it higher than it actually is.
Being the first app I had ever developed, I was pretty clueless when it came time to publish the app and in frustration of the process I mistakenly defined the version number to some extreme value because I was, at the time, getting stuck with another error that was preventing me from completely the process .. the other error which I've since forgotten exactly, was related to the version number being incorrect. So I finally thru my hands in the air, set the version number to 8 and was able to complete the process.
Since then, I'm still pretty clueless but I've learned a thing or two, and the current version of the app is 2.41. When I prepare an update on iTunes Connect I set the version to 2.41. But if I define 2.41 in CFBundleVersion or CFBundleShortVersionString, Xcode outright refuses to upload the binary and demands a version greater than the previous version which has now surmounted to 9.1.
Obviously, any users of the app would be quite confused if the version jumped from 2.41 to 9.1 overnight.
It was you who defined the new version as 2.41 in iTunes connect. Any new version should be higher than the last one. So the straightforward solution is removing the 2.41 version from iTunes Connect and add a new 9.1 version. Then iTunes Connect and your binary will be in accordance and you will be able to upload the new version.