Asyncdisplaykit: [Build / Cocoapods] 4-number Podspec version is rejected by iTunes Connect, for dynamic frameworks.

[smyrgl]

So Cocoapods uses the version number in the Podspec to version the dynamic frameworks it creates and the current 1.7.9.2 version that is specified in the podspec is not a valid version for a framework (unknown if this is a problem with Cocoapods when you don't use use_frameworks! directive and rely on static libs). Right now if I try to submit an app with ADK using Cocoapods I get this:

[00:36:21]: [Transporter Error Output]: ERROR ITMS-90060: "This bundle is invalid. The value for key CFBundleShortVersionString '1.9.7.2' in the Info.plist file must be a period-separated list of at most three non-negative integers."
[00:36:21]: Transporter transfer failed.
[00:36:21]: 
[00:36:21]: ERROR ITMS-90060: "This bundle is invalid. The value for key CFBundleShortVersionString '1.9.7.2' in the Info.plist file must be a period-separated list of at most three non-negative integers."
[00:36:21]: Return status of iTunes Transporter was 1: ERROR ITMS-90060: "This bundle is invalid. The value for key CFBundleShortVersionString '1.9.7.2' in the Info.plist file must be a period-separated list of at most three non-negative integers."
[00:36:21]: ERROR ITMS-90060: "This bundle is invalid. The value for key CFBundleShortVersionString '1.9.7.2' in the Info.plist file must be a period-separated list of at most three non-negative integers."
Return status of iTunes Transporter was 1: ERROR ITMS-90060: "This bundle is invalid. The value for key CFBundleShortVersionString '1.9.7.2' in the Info.plist file must be a period-separated list of at most three non-negative integers."

This is a very serious issue since I can't update a production app with a new ADK version obviously.

I admit that Cocoapods podspec linting should catch this but really we need another fix for this. The easiest (and least error prone) fix is simply to stop using 4 integer versions in ADK and just roll the patch version whenever we want to cut a new version tag.

[aaronschubert0]

@smyrgl Is your app in Swift? I had this issue as well recently, as well as some other issues related to the !use_frameworks command. What I had to do was not build Cocoapods using this command. The downside of this is that you can't use Swift only libs. Is this achievable?

[yury]

Agree with @smyrgl that easiest solution it to do x.y.z versioning...

[DavidSchechter]

I have the same issue to when try to submit the app I'm working on to the App store.
@appleguy what are your thought on this matter?

[vandadschibsted]

I quite frankly don't understand why everybody blames this issue on CocoaPods!

I might be wrong but look at AsyncDisplayKit's latest PodSpec, released by the one and only @appleguy

https://github.com/CocoaPods/Specs/blob/master/Specs/AsyncDisplayKit/1.9.7.2/AsyncDisplayKit.podspec.json

The version clearly in the spec says 1.9.7.2 and is 4 slices therefore is rejected by Apple. A valid version number is 3 slices only.

This issue is not in any ways related to CocoaPods or use_frameworks. Someone has to fix the version number of the Podspec please.

[yury]

@vandadschibsted I quite frankly don't understand why you give 👎 to my comment.

I know that it is not cocoapod issue at all.

And I propose to use x.y.z versioning for pods.

use_frameworks - build pods as separate libs and use versioning from pod spec and then we have issue with x.y.z.p versioning.
without use_frameworks - cocoapods build only one lib - app_pod.

[vandadschibsted]

@yury that's a workaround to fix the original problem, which is the wrong version number in the Podspec file. I stand corrected, that has nothing to do with use_frameworks or Cocoapods itself.

We have wrong version number in the Podspec and it needs to be fixed. Sure we can use a workaround and remove use_frameworks but that doesn't fix the problem. It hides it.

[yury]

@vandadschibsted we can't just remove use_frameworks with swift that would work :(

And again, yes we should use x.y.z for versioning.

[JPROFFICIAL]

Would using the static lib for ASDK solve this problem? New to versioning/podspec
Trying to find a way around this while still incorporating the framework but not losing all pods by removing use_frameworks

[yury]

@JPROFFICIAL simple workaround is to open Pods project and set correct version in AsyncDisplayKit target.

[JPROFFICIAL]

@yury Which would be what version? 1.7.9 ?

[yury]

@JPROFFICIAL yep, that would work

[smyrgl]

Here is the solution I went with in my podspec:

post_install do |installer|
    app_plist = "Disqus/Info.plist"
    plist_buddy = "/usr/libexec/PlistBuddy"

    version = `#{plist_buddy} -c "Print CFBundleShortVersionString" "#{app_plist}"`.strip

    puts "Updating CocoaPods frameworks' 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

Yes this does set the version number of all your frameworks to the value of your app but as far as I know this has no negative affects so it seems to work fine in production for me.

[smyrgl]

@aaronschubert0 Yes my app is in Swift and I use a couple of third party frameworks.

[appleguy]

@yury @smyrgl @DavidSchechter @vandadschibsted @aaronschubert0

Hey everyone, thanks for your patience here. Initially we had only one report of this. Then weeks later, a second report. Only now is it clear that this is affecting a lot of people. Most developers I've worked directly with are using the static library because of its superior performance, so I didn't realize the impact of this.

I would consider it a Cocoapods issue insofar as 1) Cocoapods permits these version numbers with no warning, and they do not cause an issue for static libraries, 2) This issue does not affect Carthage users, to my knowledge, 3) Cocoapods could easily overwrite the framework version in the metadata with any value they want, as it is not used at that stage, especially for 4-digit version numbers that their stack accepts as valid pod versions.

That said, we will push a new version of the framework in the next day or two. @maicki and I are getting ready for this unplanned release. We will need to distort the version numbering scheme and use something like 1.9.73 as we have a large amount of material tracked under the 1.9.8, etc releases and GitHub provides no batch editing functionality. So we will release that as 1.9.80. Once 2.0 is released, we will resume a strictly 3-number versioning scheme and eliminate the two-digit minor version. Let me know if you have any better ideas, but this seems like a relatively low-cost fix (annoying, but I think it is less annoying than changing all our release tracking documents and running into 1.9.10)

[smyrgl]

@appleguy I noticed that Cocoapods 1.0 at least fixed the issue with mixed static/dynamic frameworks so Swift users post-1.0 Cocoapods can at least go that route. https://github.com/CocoaPods/CocoaPods/pull/4146/commits/7b6d2edcb1b7818eabc120f832c679ec89884d2a

[appleguy]

A git tag for 1.9.7.3 is now available. The pod spec version number is 1.9.73 without the extra .

I tried to push it to pod trunk but apparently it may have failed and I don't have my machine handy (230AM / left it downstairs). Please feel free to point to that tag as it should be stable. Release should be fully pushed tomorrow sometime. You can also build against master which now has the 3-digit version.

[appleguy]

Still unable to submit this. Cocoapods is blocking it / not validating the podspec. I've spent many hours on it, and am now working with project dependencies to try to sort it out.

[appleguy]

@smyrgl @yury @aaronschubert0 @JPROFFICIAL @vandadschibsted Finally, 1.9.73 is fully pushed. See Slack's #general channel for details. Email or message me directly with any issues or feedback!

[yury]

@appleguy

  - AsyncDisplayKit/PINRemoteImage (1.9.73):
    - AsyncDisplayKit/Core
    - PINRemoteImage/iOS (>= 3.0.0-beta.2)

PINRemoteImage will break it too.