Xcode archive can not be uploaded to app store if cocoa pods links watchOS 2 libraries

[michaelochs]

Summary:
When using cocoapods inside a watchOS 2 target, Xcode builds a corrupted archive file that itself no longer identifies as iOS app but instead as 'Generic Xcode Archive'.

Steps to Reproduce:
0. Open the example project and run archive
-- or --

1. Create an iOS project containing a watchOS 2 target
2. Create a 'Podfile' in the main directory
3. Add e.g. pod 'AFNetworking' to both, the iOS and the watchOS target
4. Run 'pod install' from the command line
5. Open the .xcworkspace file
6. Click Products > Archive
7. Open the organiser and select the resulting archive

Expected Results:
The 'Upload to App Store' button is blue and can be used for submitting.

Actual Results:
The 'Upload to App Store' button is greyed out and can not be touched. The archive's Info.plist is missing the product specific informations.

Version:
Xcode 7 GM, (El Capitan GM or OS X Yosemite)

Notes:
Adding the following into the archive's Info.plist produces a valid Xcode archive that can be uploaded to the App Store without any problems:

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

Notes:
I also filed the same bug to Apple as rdar://22682898 as I don't know who is responsible for the issue, but I guess a cocoa pods fix could be made available much faster as a new Xcode release.

[neonichu]

Which version of CP did you use?

[neonichu]

NM, I can actually reproduce it with my watch apps 😞

[peterholc]

We're seeing the same thing building iOS app with an iOS 8 extension + universal framework. In a test project a universal framework without pods archives correctly, the moment a pod is added to it, it becomes generic. The archive also includes the .framework (which is empty inside) which I believe is the reason why the archive becomes generic. Hope this helps

[peterholc]

FYI just got this working with 0.39.0.beta.3
0.39.0.beta.4 has this same issue occurring.

[ay8s]

FYI I got round this by removing the Copy Pods Resources Build Phase.

[wangshengjia]

Same issue here. Eventually workaround with modifying info.plist manually, we can generate and upload successfully via Xcode 7 GM, but binary is still in status "processing" more than one hour...

EDIT
FYI now it's OK for submission finally !

[michaelochs]

Note: Apple has responded to the rdar I filed and I've uploaded them a broken .xcarchive. I also pointed them to this issue here.

[rckoenes]

I'm also having this issue , my project has no watch of any other extensions at all.
Just a simple app.

[neonichu]

@michaelochs thanks for that 👍 — I'll be looking into it from the CP side over the weekend.

[neonichu]

Seems like this is actually a race condition inside Xcode's "Archive" when having script build phases 🎉

I was able to reproduce even with a "Copy Pods Resources" build phase that is an empty shell script and was able to "solve" it by turning off "Parallelize Builds" in the schemes.

Could y'all try if just turning off that makes a difference when you archive your apps?

[michaelochs]

@neonichu If I disable parallelise builds, the outcome is the same: The generated archive is a Generic Xcode Archive.

Also Apple reported back on the bug and they see this as a third party bug with no task on their side. If we however can reproduce this issue without cocoa pods in an Xcode archive they would be interested in this. I haven't been able do this, however.

[zkrige]

Also having this issue. No watch dependencies - just a plain iOS app. Am Only getting generic xcode archive when I archive

[neonichu]

@michaelochs thanks, have you tried removing the "Copy Pods Resources" build phase entirely and did that change anything?

[zkrige]

unchecking parallelise builds does nothing for me

The only way I can get it working is to manually update the info plist in the faulty xcode archive, then restart xcode. Once I've done that, then the submit to app store is working.

Also, anything beyond 0.38.2 seems to break xcode 6.4 as well. I had to roll back to 0.38.2, clean derived data, pod install and then archive to get a working xcode 6.4 archive

[michaelochs]

@neonichu I now removed almost all build phases we have in our app, including the Copy Pods Resources build phases and also disabled Parallelize Build. That still produces an invalid archive.

[clarkcox3]

@michaelochs If you have a project that you can attach to the Apple bug report that produces the invalid archive without the involvement of the Copy Pods Resources build phase, that would be helpful.

[aeykens]

@michaelochs Have you tried clearing Private Headers Folder Path and Public Headers Folder Path for each Pod Target?
#4119 (comment)

Here is the PR:
#4217

[michaelochs]

@clarkcox3 I haven't been able to reproduce this in a clean sample project that doesn't involve cocoa pods. As soon as you add cocoa pods this issue arrises. Therefore Apple responded that this is most likely a cocoa pods issue, and it looks to me like it is as well.

[chasing]

Removing the "Copy Pods Resources" Build Phase appears to have worked for me, as well, for what it's worth.

[neonichu]

Since removing the "Copy Pods Resources" build phase at least solves this issue for a bunch of people, we should do that for 0.39 (only in case that it is empty, of course) — if anyone for whom this doesn't do the trick has an example they can share, that would be awesome.

[clarkcox3]

@michaelochs OK. I misinterpreted your previous comment as saying that you had reproduced it without Cocoa Pods' involvement. (And I agree that it looks like a Cocoa Pods issue, but I'm biased, in that I'm the Apple engineer that responded to your bug report)

[segiddins]

@neonichu we shouldn't remove the file, only make it empty (to avoid having to touch the project file). And that still won't help in the case that there are resources...

[neonichu]

@segiddins making it empty doesn't work, though, unless it is paired with disabling parallel builds, see this comment. At least that is what was happening with the example I have.

It seems to me as if this is only occurring in conjunction with frameworks integration, so there probably will be no resources. In any case, it's better to fix this for some people than for none at all, IMO.

[michaelochs]

@clarkcox3 What I did was, I removed the cocoa pods build phase and it didn't solve the issue. However it was still a cocoa pods project. So cocoa pods was maintaining the project file and all these things. I haven't been able to reproduce this in a project that had no cocoa pods involvement at all. But I'll try some things during the weekend.

Ps: Nice to see Apple engineers around here 👍

[zkrige]

Removing "Copy Pod Resources" build phase AND unchecking "Parallelize Builds" in scheme config seems to have done the trick.

I had to do both of these steps in order to fix the problem

[aytek]

Removing "Copy Pod Resources" build phase AND unchecking "Parallelize Builds" in scheme config didn't help me.

[michaelochs]

I managed to create a project without cocoa pods that has the same issue.

@neonichu The line that breaks the archive is the following from the copy resources script:

mkdir -p "${INSTALL_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}"

In fact creating any directory inside the install dir of a watch extension will break the archive. It is okay to do so in the regular iOS application phase, but as soon as this line is also included inside the watch extension script, it doesn't work.

@clarkcox3 I added a sample project without cocoa pods to the bug that I already marked as resolved (rdar://22682898), I hope that is okay. Otherwise let me know and I will open another rdar.

[aytek]

I'm not sure but after adding use_frameworks! in pod file, I can upload to iTunes Store.

[clarkcox3]

@michaelochs A second bug would be helpful. Make sure to mention my name and the old radar number in it; It may or may not still be considered a bug for Cocoa Pods to deal with, but I'll make sure it gets investigated.

[michaelochs]

@clarkcox3 rdar://22875811

[michaelochs]

@neonichu another thing that came to my mind wile digging into this: Should I open a new issue for this? When copying resources of a pod that is added to a watch kit extension, the resources theoretically need to be copied to the watch app, not the extension.

[neonichu]

@michaelochs Yep, good point — I guess we were assuming most people will use frameworks for their watch apps, so resources will be kept in those. Please open an additional issue for that 👍

[mathiasAichinger]

@neonichu We have the same problem and it's affecting the WatchKit extensions and the Widget extension. We are getting two extension products (zero byte) in the products folder of the .xcarchive. Now I tried to remove the shell script lines which @michaelochs highlighted and it's working again.

[jgonfer]

I've been trying to fix the problem with all that you've said here, but I still getting this error when archiving the app:

error: module file was created for incompatible target armv7-apple-ios8.0: /Library/Developer/Xcode/DerivedData/B2B-dknnmkplfuhntmbjfxavlmufuiif/Build/Intermediates/ArchiveIntermediates/B2B/BuildProductsPath/Release-watchos/Pods-B2B WatchKit Extension/Alamofire.framework/Modules/Alamofire.swiftmodule/arm.swiftmodule
import Alamofire
       ^

And even downgrading to version 0.39 beta 3 it doesn't work.

I'm using the podfile:

platform :ios, '8.0'

use_frameworks!
link_with 'B2B', 'B2B WatchKit Extension'
link_with 'B2B', 'B2B Free'

def shared_all_pods  
  pod 'Alamofire', '~> 3.0'
end

def shared_app_pods
  pod 'RealmSwift', '0.95.3'
  pod 'SwiftyJSON', '~> 2.3'
end

target 'B2B' do
  shared_all_pods
  shared_app_pods
  pod 'MMWormhole', '~> 2.0'
end
target 'B2B Free' do
  shared_all_pods
  shared_app_pods
end
target 'B2B WatchKit Extension' do
  platform :watchos, '2.0'
  shared_all_pods
  pod 'MMWormhole', '~> 2.0'
end

I also tried what #4369 says, but with no success results. I was not sure if I should open a new issue, so I wrote here :)

[jcampbell05]

Got this same problem,too, the archive has a iOS app with a watch app inside of it as well as the watch app.

[neonichu]

I have an ongoing branch for this, but it is not at all ready, yet. I'll try to get back to it next week.

[jcampbell05]

So a workaround for Fastlane has now been merged, so if people use that to build and push to iTunes then it will work.

[stale]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍