Xcode 7.1 - fails to upload to App Store; complains about CFBundleVersionShort string

Figured it out - and its a bug in Xcode.

We have a third party resources bundle that we include with our app. It has a version number of 1.0 in there. I had to change THEIR version number to match mine.

Seems like a bug to me as that bundle didn't even have code in it - why was iTC/Xcode so concerned with that bundle info.plist rather than mine?

rdar://23210707

😠

Same issue here, all pod frameworks are rejected because they don't have a higher version than my previous app version. So I have 1.1.3 in the app store and I'm strying to submit 1.1.4, but ISO8601DateFormatter 0.7 won't go through because it's supposed to have version >= 1.1.4 (which is totaly unrelated).

We are running into the same issue, did you find out why its picking the wrong bundle id?

Its obviously a bug in Xcode 7.1. I filed a bug with Apple and downloaded Xcode 7.01.

I'm not 100% sure it's Xcode. I am still using XCode 7.0.1 and I was able to submit with it 2 weeks ago. Also, my first 2 rejections today came as *email* from iTC, the XCode uploads succeeded. Furthermore, I was able to upload 2 binaries yesterday. Neither XCode, nor my cocoapods have changed since then.

I'm pretty sure this is iTC code that was deployed early today.

Same here: I was able to submit builds last week using the same project structure and same version of Xcode that is failing today. Earlier today the uploads succeeded and I then I received "invalid binary" emails from ITC. Later in the day, the uploads started failing during the submission to ITC. Since the behavior has changed twice (from working, to failing after upload, to failing during upload) with no intervening changes to my project structure and no intervening Xcode upgrades, I am left believing that this is a result of a bug from a server-side update to ITC today. (Also, I am on Xcode 7.0 here, haven't upgraded to 7.1 yet, so that blows the theory that this is an Xcode 7.1 bug).

We're seeing this as well.

On version 7.0.1 (7A1001) of xcode and all builds are rejected due to the CFBundleShortVersionString.

The annoying part is the reported string is [0.1.12] when my app is clearly set to [1.1].

After some searching the version of APAddressBook we're using was at 0.1.12.

I changed the info.plist for APAddresBook to match my app and ... it worked. At least as far as getting a build uploaded. Hopefully the underlying issue (clearly an APple issue) will be fixed soon to avoid the monkey business.

Also seeing this, XCode 7.0.1. This is the first day we've tried to submit so I ant' confirm if this is new behavior. We also use Cocoapods with embedded frameworks and it's complaining about the version number being invalid in either the incorrect format (not 3 decimals) or lower than our previous app bundle version. 😠

filed rdar://23214096

Same here and thanks. The workaround worked for my case.

1. Find all third party bundle and its info.plist

2. Change version number from 1.0 to your build number e.g. 1.2.2

3. Rebuild and upload

post_install do |installer|
  app_plist = "Emergence/Info.plist"
  plist_buddy = "/usr/libexec/PlistBuddy"
  version = `#{plist_buddy} -c "Print CFBundleShortVersionString" #{app_plist}`.split
  puts "Updating CocoaPods' version numbers to #{version}"


  installer.pods_project.targets.each do |target|
    `#{plist_buddy} -c "Set CFBundleShortVersionString #{version}" "Pods/Target Support Files/#{target}/Info.plist"`
  end
end

You can automate setting all of the CocoaPods' framework bundles with this post install hook. Obviously you need to change your app_plist to be whatever is the key one.

It seems to be a new rule of iTC not related to Xcode version: I'm getting the same error while using iTMCTransport -m verify (Xcode 7.0.1)

As far as I understood the error message I got: bundled frameworks should bump their versions, not to match the version of the app.

It's important to note that some frameworks might depend on particular version number (featues availability check, bugs workarounds etc), so I would rather avoid changing it.

Has anyone found any way around this error without modifying 3rd party dependancies?

You gotta be kidding me.....every release they mess something up so that I cannot submit for days until someone figures out how to circumvent these bugs.

It worked for me this morning.