Xcode 7 GM ITC submission - "Invalid Swift Support" - multiple Swift libraries in WatchKit App

I can (finally) submit without apparent errors, but then I receive this email:


Dear developer,

We have discovered one or more issues with your recent delivery for "Xxxx". To process your delivery, the following issues must be corrected:

Invalid Swift Support - The Watch OS application has Swift libraries at both /Payload/Xxxx.app/Xxxx WatchKit App.app/Xxxx WatchKit Extension.appex/Frameworks/ and /Payload/Xxxx.app/Xxxx WatchKit App.app/Frameworks/. Remove all of the Swift libraries from one of the locations and resubmit your app.

Once these issues have been corrected, you can then redeliver the corrected binary.

Regards,

The App Store team


I assume it's NOT telling me to edit the ipa to remove the duplicate libraries. But I don't know what Build Settings or other configuration is driving the generation of duplicate libraries in the payload.


Advice?

Accepted Reply

I discovered that changing "Embedded Content Contains Swift Code" from YES to NO in the main app build settings (and leaving it set to YES in the extension) would run on the watch (and the phone). At the same time as I uploaded that binary, Apple must have made a change to the ITC backend as my other uploaded builds which had been marked "Invalid Binary" reverted to "Processing" and later passed the screen to "Inactive".


So I submitted the build with "Embedded Content Contains Swift Code" YES in the extension only for review.

Replies

My anwer from here: https://forums.developer.apple.com/thread/17063?sr=stream&ru=18990


Possible solution:


After struggling with this for three days now, we do have a solution that works for us and hopefully works for some of you as well:


It seems like that creating the .ipa your self e.g. through a continuous integration server is NOT possible anymore as it then contains the wrong swift and watch kit support files. So the first thing you should try is:


Archive and upload your app through Xcode 7 GM.


This, however, didn't work for as either as the 'Upload to App Store...' button was grayed out because Xcode marked the created archive as 'Generic Xcode Archive' instead of 'iOS App Archive'.


It turns out, this happens when you have cocoapods link a framework to a watchOS 2 application.


To fix this we had to digg a little bit deeper into the archive: Open the archive in the Finder, right click on it and chose 'Show package contents'. Open the 'Info.plist' of the archive in a text editor and add the following:


<key>ApplicationProperties</key> 
<dict> 
  <key>ApplicationPath</key> 
  <string>Applications/<<APP_NAME>>.app</string> 
  <key>CFBundleIdentifier</key> 
  <string><<BUNDLE_IDENTIFIER>></string> 
  <key>CFBundleShortVersionString</key> 
  <string><<YOUR_MARKETING_NUMBER>></string> 
  <key>CFBundleVersion</key> 
  <string><<YOUR_BUILD_NUMBER>></string> 
  <key>SigningIdentity</key> 
  <string>iPhone Distribution: <<CERTIFICATE_NAME>> (<<CERTIFICATE_ID>>)</string> 
</dict>


If you have an old, working archive, you can copy the values from there and simply change the marketing version and the build number.


After closing Xcode and restarting it, the archive was shown as 'iOS App Archive' and we could successfully upload the binary to the app store through Xcode.


Note: I filled the ipa generation issue under rdar://22683061 and the cocoapods releated archive building issue under rdar://22682898

I had the same issue, but was a able to fix it by changing an Build Setting:


  1. Open the Build Settings for Xxxx WatchKit Extension
  2. Change "Embedded Content Contains Swift Code" from Yes to No

Changing "Embedded Content Contains Swift Code" from Yes to No in the WatchKit Extension build settings does eliminate the invalid binary/email, but then the watch app doesn't launch on the watch (most likely because the extension is written in Swift). If I change it back to YES (the only change) and install the exported ipa, the watch app installs and runs successfully.


So I'm still stuck.

I discovered that changing "Embedded Content Contains Swift Code" from YES to NO in the main app build settings (and leaving it set to YES in the extension) would run on the watch (and the phone). At the same time as I uploaded that binary, Apple must have made a change to the ITC backend as my other uploaded builds which had been marked "Invalid Binary" reverted to "Processing" and later passed the screen to "Inactive".


So I submitted the build with "Embedded Content Contains Swift Code" YES in the extension only for review.

Just to be clear on your solution:


Main app: Embedded Content Contains Swift Code = NO

WatchKit extension: Embedded Content Contains Swift Code = YES


Is that correct?