i keep on receiving this email after sometime i upload my IOS new version IPA to ITunes. But i don't know what does it mean anymore. My build version current is been increase to "0.0.27" due to upload keep on failing me. My CFBundleShortVersionString also increase to 97 due to some mistake in previous upload numbering. But i still can't seem to upload my IOS update to Itunes. Im doing phonegap cross-platform mobile application. First version is successful on 14 February 2018, and upload by appsuploader. Any clue for what i miss will be appreciated.
Invalid Version - The build with the version “0.0.15” can’t be imported because a later version has been closed for new build submissions. Choose a different version number.
Invalid or Non-Increasing CFBundleShortVersionString - The value specified in the bundle's Info.plist file for the key CFBundleShortVersionString must be a string consisting of at most three dot-separated components, where each component is composed only of the digits 0 through 9. For example, any of the following are syntactically valid values for CFBundleShortVersionString: "1.0", "4.2.1", "3.46", "1.112.0"; whereas the following are all syntactically invalid: "1.4.0.0.0.0.5", "GX5", "3.4.2b6", "2.6GM", "1.0 (Gold)", "-3.6". Additionally, each updated version of the same application must have a CFBundleShortVersionString that increases relative to that of the previous version that was actually made available for sale on the iTunes Store. For example, if a previously-available version had a CFBundleShortVersionString of "1.4", then any of the following would be acceptable as the next update: "1.4.1", "1.4.332", "1.5"; but all of the following (though syntactically valid) would be unacceptable: "1.4", "1.3", "1.3.9", "0.9". For more information about the CFBundleShortVersionString key and the Info.plist file, see Apple's Runtime Configuration Guidelines at http://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPRuntimeConfig/index.html
Mark this as Resolve. It just an compilation conflict when selecting android and ios together. I compile the cross platform individually then can see the adobe phonegap build version is changing to latest. After that upload to ITunes and everything go smooth.
Related
When trying to upload the latest greatest app version of our app to App Store Connect we are getting the following error: This bundle is invalid. The value for key CFBundleShortVersionString [2.1.0] in the Info.plist file must contain a higher version than that of the previously approved version [1565960106]. I understand that you cannot upload version 1.0 after 2.0, but in our case we're not planning to make our version higher than 1565960106. How can we get rid of this strange high number?
Side note: the store version is 2.0, there is indeed a faulty version where the build number was used as version number and that one was approved for external testers, but never released to the store.
I have been releasing my App (Desktop, Android & iOS) until today. without any visible reason, I keep getting the same error message:
Error occurred while packaging the application:
Warning: Invalid format specified <versionLabel> tag. Ignoring its value.
I can release Desktop and Android packages but not iOS!
Logically, the error message is wrong.
I am working on Windows 10 and Flash Builder 4.7.
Please help!
I don't package for iOS but from a quick research of your problem...
(1)
If you are putting version number as 1.2.3.4.5 etc then it must actually be only as : 1.2.3
From AIR 18 SDK onwards,
the value of versionLabel is mapped to CFBundleShortVersionString
the value of versionNumber is mapped to CFBundleVersion.
See Apple documentation : CFBundleShortVersionString and also CFBundleVersion
Pay attention to "The release version number is a string composed of three period-separated integers" and the warning "The value for this key is different from the value for CFBundleVersion"
(2) Try updating to the latest AIR SDK (sometimes these issues are already fixed in new version).
My issue is solved.
I removed the versionLabel value, then I tried to package again and I got the right error message:
Certificate expired.
From there onwards (make new certificate) I can package like before.
I've been trying to upload a new build to iTunes Connect to update an app. I first used xCode 6 but got a email from Apple stating this:
Dear Developer,
We have discovered one or more issues with your recent delivery for "App". To process your delivery, the following issues must be corrected:
Invalid Swift Support - The files libswiftDarwin.dylib, libswiftDispatch.dylib, libswiftCoreGraphics.dylib, libswiftUIKit.dylib, libswiftContacts.dylib, libswiftCore.dylib, libswiftCoreAudio.dylib, libswiftFoundation.dylib, libswiftXCTest.dylib, libswiftCoreImage.dylib, libswiftObjectiveC.dylib aren’t at the expected location /Payload/App.app/Frameworks.
Move the file to the expected location, rebuild your app using the current public (GM) version of Xcode, and resubmit it.
Once these issues have been corrected, you can then redeliver the corrected binary.
I thought it was a simple fix, so I just updated to the latest GM (Xcode 7.2) & completed the Swift 2 migration, however I received the same email. Could someone explain how to solve this and what those files are? This isn't a "files don't match" problem as seen in other questions.
I stumbled upon this as I've encountered the same problem. It's the first time I've been tasked with handling the release of a Swift app to the App Store.
I found that this answer by TALAA works a treat: https://stackoverflow.com/a/26949219/1567836
There is an "Embedded Content Contains Swift Code" flag in the Build Settings that needs to be set to YES. After setting this, clean the project before building again.
After the clean, you'll have to recreate a build to upload to the App Store. You might find that the new upload will get rejected claiming that a binary already exists for that number. If you update the build number (has to be larger than the previous one) then the new upload will be accepted.
As per the #Thomas You need to enable that flag and after that for the "Invalid Swift Support", I had the issues with Application Loader since Xcode 6.4. So, I started uploading the app from the "Organizer" (Xcode > Window > Organizer > Upload to App Store).
This solves the problem.
Inspect the payload and also the SwiftSupport folder in the .ipa file (by converting it to a .zip) and make sure the libraries in the email match across both those directories. Those need to match apparently.
You should probably not have libswiftXCTest.dylib in the Payload/App.app/Frameworks or SwiftSupport folders in something you're submitting to Apple. If you do, check the build section of the scheme for your App target and make sure you aren't including any test targets in your Archive step.
ERROR ITMS-9000: "Missing or invalid signature. The bundle 'com.google.GPPSignIn3PResources' at bundle path 'Payload/My_app_name.app/GooglePlus.bundle' is not signed using an Apple submission certificate."
I was able to submit same build previously now just did UI related few changes and trying to resubmit the build and getting this error. Is there any solution to handle this ??
The same problem as described here: AppStore Submission - Missing or invalid signature - com.google.GPPSignIn3PResources
Just remove files below and build your app as usual!
GooglePlus.bundle/GPPSignIn3PResources
GooglePlus.bundle/GPPCommonSharedResources.bundle/GPPCommonSharedResources
GooglePlus.bundle/GPPShareboxSharedResources.bundle/GPPShareboxSharedResources
Upgrade to the 1.7.1 version of the Google Plus iOS SDK
Difference between 1.7.0 and 1.7.1 bundles is that no files were added but following three files are deleted.
Or
Delete following 3 files from 1.7.0
GooglePlus.bundle/GPPSignIn3PResources
GooglePlus.bundle/GPPCommonSharedResources.bundle/GPPCommonSharedResources
GooglePlus.bundle/GPPShareboxSharedResources.bundle/GPPShareboxSharedResources
A more than one binary may be uploaded to iTunesConnect if the the Build number (Select the Target, then Xcode -> General -> Build, see the picture below) is increased by adding .1, i.e. if the version is 3.75, then increase it to: 3.75.1, but the Version is still `3.75 for the App (also in iTunesConnect). The build number just has to be unique for each binary that is loaded up to iTunesConnect.
After a new binary is uploaded and processed (~ 10 min), then you can select the new binary and submit it for review. In the picture below you may see the old and the new binary listed in iTunesConnect in the Build section of the current App version (you click the plus sign). Then the new binary is selected -> Saved -> Submit for Review. (Sometimes an error comes when submitting, then just try after a few mins or upload a new binary build).
For those inclined to do this automatically with an Xcode script, here is a description of making an automatic script for updating Build numbers Better way of incrementing build number?
According to g+ docs, GooglePlus.bundle shouldn't be added to the project
I'm using xcode 6 GM and updated g + to it's latest version (removing GooglePlus.bundle) from the project and got rid of that error
ref: https://developers.google.com/+/mobile/ios/getting-started
(You might run also in an arm64 error if you don't add arm64 to the Valid Architectures in Build Settings)
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