'Invalid Swift Support' email from iTunes when submitting with Xcode 7 GM & Cocoapods

[earltedly]

Problem

Since building with Xcode 7 GM, I'm getting the following email back from Apple which fails submission:

Invalid Swift Support

The files libswiftCoreLocation.dylib, libswiftCoreMedia.dylib, libswiftCoreData.dylib, > libswiftAVFoundation.dylib don’t match

/Payload/App.app/Frameworks/libswiftCoreLocation.dylib, /Payload/App.app/Frameworks/libswiftCoreMedia.dylib, /Payload/App.app/Frameworks/libswiftCoreData.dylib, /Payload/App.app/Frameworks/libswiftAVFoundation.dylib

Make sure the files are correct (?), rebuild your app, and resubmit it.

Don’t apply post-processing to

/Payload/App.app/Frameworks/libswiftCoreLocation.dylib, /Payload/App.app/Frameworks/libswiftCoreMedia.dylib, /Payload/App.app/Frameworks/libswiftCoreData.dylib, /Payload/App.app/Frameworks/libswiftAVFoundation.dylib.

Workaround

There's a workaround on Stackoverflow which seems to work:

1. Archive your app with new build number :(
2. Find the archive (.xcarchive file) in Finder from Organizer “Show in Finder”
3. Open the package and find directories like Products/Applications/YourApp.ipa/Frameworks/ and SwiftSupport/iphoneos/
4. Copy all libswiftXxx.dylib files from SwiftSupport/iphoneos/ into Products/Applications/YourApp.ipa/Frameworks/ and overwrite
5. Now, Upload to App Store from Organiser

Cocoapods relevance

I had a look around in Pods-frameworks.sh and found a section commented as:

Embed linked Swift runtime libraries

Commenting the block of code which copies these libraries across (and code signs them) seems to have fixed my submission woes. I've not dived in deeper yet to see if it's just the copying of them which causes the issues or if it's the code-signing. I'm getting a bit out of my depth there.

[falsecz]

Stackoverflow workaround works for me
Xcode 7 GM, CocoaPods 0.39.0.beta.4

[earltedly]

Just edited my original issue to make it clear where I think Cocoapods might be aggravating things.

[itspradhan]

Does CocoaPods 0.39.0.beta.4 fix this issue or we need to follow the workaround ?

[earltedly]

It doesn't fix it that I'm aware of.

On 18 Sep 2015, at 06:35, Pradhan george notifications@github.com wrote:

Does CocoaPods 0.39.0.beta.4 fix this issue or we need to follow the workaround ?

—
Reply to this email directly or view it on GitHub.

[itspradhan]

I really hope cocoapods would fix this issue soon.

[orkenstein]

Really annoying. Please fix!

[segiddins]

Piling onto the issue won't get it fixed any faster. At the moment, most of the team is very busy dealing with different pieces of travel, so the fastest way to get a fix landed would be to submit a PR.

[djtarazona]

Commenting the block of code which copies these libraries across (and code signs them) seems to have fixed my submission woes. I've not dived in deeper yet to see if it's just the copying of them which causes the issues or if it's the code-signing. I'm getting a bit out of my depth there.

@earltedly Commenting out those lines solved the issue for you? How are you building your app? Just archiving via Xcode? Or using something like gym? If these lines are commented out... wouldn't that mean necessary Swift files are left out?

[chrisballinger]

I am also experiencing this problem and have only tried the StackOverflow workaround, but it's good to know there might be a root cause from the CocoaPods script.

[djtarazona]

As @earltedly suggested, commenting out the following lines in Pods-frameworks.sh solved all issues for me! Builds to the simulator from Xcode work, archiving from Xcode works, and builds with gym work.

  # Embed linked Swift runtime libraries
  local basename
  basename="$(basename "$1" | sed -E s/\\..+// && exit ${PIPESTATUS[0]})"
  local swift_runtime_libs
  swift_runtime_libs=$(xcrun otool -LX "${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}/${basename}.framework/${basename}" | grep --color=never @rpath/libswift | sed -E s/@rpath\\/\(.+dylib\).*/\\1/g | uniq -u  && exit ${PIPESTATUS[0]})
  for lib in $swift_runtime_libs; do
    echo "rsync -auv \"${SWIFT_STDLIB_PATH}/${lib}\" \"${destination}\""
    rsync -auv "${SWIFT_STDLIB_PATH}/${lib}" "${destination}"
    code_sign_if_enabled "${destination}/${lib}"
  done

I feel like the fix isn't this simple tho. Is Xcode 7 taking care of copying the appropriate Swift runtime libraries now?

@segiddins I'll create a pull request with this solution then.

[earltedly]

I feel like the fix isn't this simple tho. Is Xcode 7 taking care of copying the appropriate Swift runtime libraries now?

@djtarazona I think a possible edge-case would be a scenario where you have a purely Objective-C project which makes use of cocoa pods containing Swift frameworks. I believe there's a build setting which tells Xcode about this EMBEDDED_CONTENT_CONTAINS_SWIFT.

[orkenstein]

@earltedly, my project is 100% swift2 project.

[miottid]

Same here :)

[orta]

have you tried using this branch? #4221

[miottid]

This branch did the trick thanks

[hatemalimam]

The workaround works, but it's annoying to do each time :/

Another thing to add up, when I submit the app the processing phase is never finished !

[ishortman]

FYI...updated to 0.39.0.beta.4 and still the same issue invalid swift support when I try to submit to the app store for beta testing. Currently using the latest xcode 7 and code is written in swift. I tried various hacks and nothing seems to fix this issue.

Invalid Swift Support - The files libswiftWebKit.dylib, libswiftCoreLocation.dylib don’t match /Payload/.app/Frameworks/libswiftWebKit.dylib, /Payload/.app/Frameworks/libswiftCoreLocation.dylib.

[hatemalimam]

With 0.39.0.beta.4 still having the same problem. When can we test this ? next release ?

[neonichu]

I don't believe we need any more info on this for now — you can use the branch from #4221 as a workaround, see https://guides.cocoapods.org/using/unreleased-features on more info how to do it.