Cocoapods: Failure to archive with new build system, extensions, and subspec combinations

[paulb777]

• [X] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.
  🌈

Report

What did you do?

Product -> Archive

What did you expect to happen?

Successful archive

What happened instead?

error: Multiple commands produce '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gpaqorhpcdsnzfbjncbmklpefpai/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GTMSessionFetcher.framework':
1) Target 'GTMSessionFetcher-Core' has create directory command with output '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gpaqorhpcdsnzfbjncbmklpefpai/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GTMSessionFetcher.framework'
2) Target 'GTMSessionFetcher-Core-Full' has create directory command with output '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gpaqorhpcdsnzfbjncbmklpefpai/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GTMSessionFetcher.framework'

CocoaPods Environment

Also occurs with 1.6.0

Stack

   CocoaPods : 1.5.3
        Ruby : ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-darwin17]
    RubyGems : 2.6.13
        Host : Mac OS X 10.13.6 (17G65)
       Xcode : 10.0 (10A255)
         Git : git version 2.19.0.605.g01d371f741-goog
Ruby lib dir : /Users/paulbeusterien/.rbenv/versions/2.4.0/lib
Repositories : cpdc-eap-spec - sso://cpdc-eap/spec @ 0fd9263ede63bee9aec1034b38771950cd7e147a
               cpdc-internal-spec - sso://cpdc-internal/spec @ 98ecdc63c0d9c742bd186a2da06b64e3b40899dd
               cpdc-test-spec - sso://cpdc-test/spec @ 00c36f2a45e0fabc743572254402411c8493396e
               master - https://github.com/CocoaPods/Specs.git @ f5bb69af3467f6ccb449624f29a53a388167a445
               temp-specs - [email protected]:paulb777/Specs.git @ e945099cd9c9d8b8a34cc583662c9a2b150893f0

Installation Source

Executable Path: /Users/paulbeusterien/.rbenv/versions/2.4.0/bin/pod

Plugins

claide-plugins         : 0.9.2
cocoapods-deintegrate  : 1.0.2
cocoapods-dependencies : 1.1.0
cocoapods-generate     : 1.0.0
cocoapods-packager     : 1.5.0
cocoapods-plugins      : 1.0.0
cocoapods-rome         : 1.0.0
cocoapods-search       : 1.0.0
cocoapods-stats        : 1.0.0
cocoapods-trunk        : 1.3.1
cocoapods-try          : 1.1.0
cocoapods_debug        : 0.1.0

Podfile

platform :ios, '9.0'

use_frameworks!

target 'MessageExtension' do
  pod 'GTMSessionFetcher/Core'
end

target 'NewBuild-Extension-Subspec' do
  pod 'GTMSessionFetcher/Full'

end

Project that demonstrates the issue

https://github.com/paulb777/NewBuildExtensionSubspec

Likely a direct result of creating two build targets for the GTMSessionFetcher CocoaPod:

[tomspee]

I've the exact same issue with multiple targets that use different iOS versions (10.0 & 12.0)

error: Multiple commands produce '/Users/tomspee/Library/Developer/Xcode/DerivedData/Company-hhmrvgkwkpelmlewuxvhclfggdtc/Build/Intermediates.noindex/ArchiveIntermediates/Company/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/ObjectMapper.framework':
1) Target 'ObjectMapper-iOS12.0' has create directory command with output '/Users/tomspee/Library/Developer/Xcode/DerivedData/Company-hhmrvgkwkpelmlewuxvhclfggdtc/Build/Intermediates.noindex/ArchiveIntermediates/Company/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/ObjectMapper.framework'
2) Target 'ObjectMapper-iOS10.0' has create directory command with output '/Users/tomspee/Library/Developer/Xcode/DerivedData/Company-hhmrvgkwkpelmlewuxvhclfggdtc/Build/Intermediates.noindex/ArchiveIntermediates/Company/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/ObjectMapper.framework'

@paulb777 Did you manage to fix this issue?

[paulb777]

@tomspee So far, I only have the workaround of changing the Podfile so that extensions don't use a different subset of subspecs that the app. Your issue may be different - same symptom, but different cause.

[vinceis1337]

I have the same issue.

I think the reason that there are duplicate frameworks could be because there are multiple projects in the same workspace. It appears to be due to how the naming works when creating frameworks.

We have a dependency
pod 'Appboy-iOS-SDK'
which defines a subspec dependency

  s.subspec 'ContentCards' do |scc|
    scc.source_files = 'AppboyUI/ABKContentCardsViewController/ContentCardsViewController/**/*.*', 'AppboyUI/ABKUIUtils/**/*.*', 'AppboyKit/ABKSDWebImageProxy.m'
    scc.resource = 'AppboyUI/ABKContentCardsViewController/ContentCards_Resources/**/*.*'
    scc.dependency 'Appboy-iOS-SDK/Core'
    scc.dependency 'SDWebImage/GIF', '~>4.0'
  end

We have a separate dependency
pod 'SDWebImage' which defines a default subspec s.default_subspec = 'Core'

Because SDWebImage/GIF depends on SDWebImage/Core, the system builds the Core framework for each project that needs it.

This causes our workspace to have a collision with two frameworks named:
"${BUILT_PRODUCTS_DIR}/SDWebImage.default-GIF/SDWebImage.framework",
and
"${BUILT_PRODUCTS_DIR}/SDWebImage-Core-GIF/SDWebImage.framework",

Note that these are in two separate projects but compiling down into one app.

[tomspee]

I've been testing for a while and I've created an empty project with just 2 targets, one main project and one widget. In the Podfile both targets (with different platforms, iOS 10 & 12) use just one shared pod, Alamofire. Also then I'm getting the same errors.

@vinceis1337 Do you have a solution/workaround?

[vinceis1337]

@tomspee Workaround is to specify subspec explicitly i.e.

pod 'SDWebImage'
change to
pod 'SDWebImage/Core'

This causes the build product path to always have the subspec name (in this example -Core-instead of -.default-)

Hmm..this might not work for you though because I don't think Alamofire has subspecs does it?

Could you post the error logs?

[sirghi]

Same problem here. Even though the targets contain the subspec names (-Core-...), they still produce the same framework name in the Products, leading to the build failure.

[levigroker]

Yep. I'm seeing this in our project using a pod with multiple sub-specs referenced from different targets. This is a show stopper... 1.6.0.beta.2.

error: Multiple commands produce '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/CASComponentLibrary.framework':
1) Target 'Foo-FoundationExtensions-Model' has create directory command with output '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework'
2) Target 'Foo-FoundationExtensions-Logging-Model-SecureStore' has create directory command with output '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework'
3) Target 'Foo-55ceec23' has create directory command with output '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework'

Please note the suggested workaround gives no relief.

Additionally, I have a lot of related warnings coming from the build system. Notably unexpected mutating task and duplicate output file (which has nothing to do with inadvertently included plist files).

Build system information
warning: unexpected mutating task ('SetOwnerAndGroup xcodeserver:staff /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') with no relation to prior mutator ('SetOwnerAndGroup xcodeserver:staff /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') (in target 'Foo-FoundationExtensions-Model')

Build system information
warning: unexpected mutating task ('SetOwnerAndGroup xcodeserver:staff /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') with no relation to prior mutator ('SetOwnerAndGroup xcodeserver:staff /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') (in target 'Foo-FoundationExtensions-Model')

Build system information
warning: unexpected mutating task ('SetMode u+w,go-w,a+rX /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') with no relation to prior mutator ('SetMode u+w,go-w,a+rX /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') (in target 'Foo-FoundationExtensions-Model')

Build system information
warning: unexpected mutating task ('SetMode u+w,go-w,a+rX /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') with no relation to prior mutator ('SetMode u+w,go-w,a+rX /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework') (in target 'Foo-FoundationExtensions-Model')

Build system information
warning: duplicate output file '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSDecimalNumber+Creation.h' on task: CpHeader /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/Source/MyProject/Pods/Foo/CCLFoundationExtensions/CCLFoundationExtensions/NSDecimalNumber+Creation.h /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSDecimalNumber+Creation.h (in target 'Foo-FoundationExtensions-Logging-Model-SecureStore')

Build system information
warning: duplicate output file '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSJSONSerialization+Safe.h' on task: CpHeader /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/Source/MyProject/Pods/Foo/CCLFoundationExtensions/CCLFoundationExtensions/NSJSONSerialization+Safe.h /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSJSONSerialization+Safe.h (in target 'Foo-FoundationExtensions-Logging-Model-SecureStore')

Build system information
warning: duplicate output file '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSObject+NilTolerantEqual.h' on task: CpHeader /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/Source/MyProject/Pods/Foo/CCLFoundationExtensions/CCLFoundationExtensions/NSObject+NilTolerantEqual.h /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSObject+NilTolerantEqual.h (in target 'Foo-FoundationExtensions-Logging-Model-SecureStore')

Build system information
warning: duplicate output file '/Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSString+Utils.h' on task: CpHeader /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/Source/MyProject/Pods/Foo/CCLFoundationExtensions/CCLFoundationExtensions/NSString+Utils.h /Users/xcodeserver/Library/Caches/XCSBuilder/Bots/82a75fec2007332e806edaa27b01db63/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/MyProject/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Foo.framework/Headers/NSString+Utils.h (in target 'Foo-FoundationExtensions-Logging-Model-SecureStore')

[rostopira]

Any progress on this?
I need SDWebImage/WebP pod in app and in notification extension
Current workaround is to use carthage for extension, and cocoapods for app, but it feels weird

[paulb777]

This issue seems related to #7733 where @segiddins says "CocoaPods can only embed a single framework with a given name, so you're not able to expose different functionality to the extension and the main app by using subspecs". However, this issue is different since these examples work fine with the old build system.

[paulb777]

I'm working on a fix to make sure that an extension target's pod targets include the subspec combinations of its host app.

[paulb777]

I got a fix working for the basic case of directly depending upon different subspec combinations.

However, I'm not sure what to do about the case where the subspec combination is coming transitively via another target. It doesn't seem right to try to change that other target.

I'm starting to think that subspecs are not scalable for source pods, since they imply different variations of the same named library could be needed and different variations of the same-named library does not work well with the Xcode builder and loader.

Should CocoaPods be change or have an option to build a different library for each subspec?

[dnkoutso]

I think we need to rethink subspecs entirely in 2.x.

[paulb777]

Here's an update from my ongoing investigation:

For subspecs from dynamic frameworks pods, there could have easily been load failures with the old build system depending on which subspec combination got copied into the app's Frameworks folder and which symbols are being used from which targets. For any workspace that ends up with different subspec combinations between an extension and the host app, it should be possible to make it fail at load time by calling methods from subspec combination that didn't get copied to the bundle. Therefore, it is arguable that the new archive failure is a good thing - although it would be much better for the build system to give the error - or at least a warning - in a regular build instead of waiting until archiving to expose it.

For subspecs from static frameworks pods, regular builds with the old and new build systems should always work fine because the right frameworks are built into appropriately labeled directory and properly linked into the right build targets. It doesn't matter which frameworks are copied into the bundle since static frameworks are linked at build time and not needed at load time.

The issue with the new build system is that the archiver wants to put all intermediate frameworks into the same directory instead of separate directories for each build target like the regular builder. I'm thinking about flushing this out a bit further and sending a Radar.

error: Multiple commands produce '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gaeuwroouqpzwlfwgiqtmknxbqjt/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GoogleUtilities.framework':
1) Target 'GoogleUtilities-NSData+zlib' has create directory command with output '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gaeuwroouqpzwlfwgiqtmknxbqjt/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GoogleUtilities.framework'
2) Target 'GoogleUtilities-Environment' has create directory command with output '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gaeuwroouqpzwlfwgiqtmknxbqjt/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GoogleUtilities.framework'

[paulb777]

https://openradar.appspot.com/radar?id=5038526135533568

[federicocappelli]

The issue is still present in 1.6.0-rc1, the only solution for me was to switch back to the old build system.

[nikolay-kapustin]

https://openradar.appspot.com/radar?id=5038526135533568

I hope Apple fix that soon.

[sprynmr]

However, I'm not sure what to do about the case where the subspec combination is coming transitively via another target. It doesn't seem right to try to change that other target.

Yeah I'm running into this. We have two different google pods included. One requires GTMSessionFetcher and the others just include GTMSessionFetcher/Core. Even changing the prior to the GTMSessionFetcher/Full subspec doesn't work.

Not exactly sure what to do about this. Any other workarounds?

[paulb777]

Maybe I'm misreading, but changing GTMSessionFetcher to GTMSessionFetcher/Full is a no-op since Full is the default subspec. The targets that require GTMSessionFetcher/Core should be changed to require GTMSessionFetcher/Full.

[sprynmr]

Yeah, you are exactly right. That's what I determined. Unfortunately I can't fix that without a bunch of PRs to various google pods or hosting a pod spec for it locally.

[paulb777]

@sprynmr You should be able to add pod 'GTMSessionFetcher/Full' to the targets in the Podfile.

[sprynmr]

I can add their targets to my Podfile and override their podspec? To be clear, we include a couple google dependencies, which in turn include either GTMSessionFetcher or GTMSessionFetcher/Core in their podspec, thus the two targets created in my Pods workspace. I can override that without hacking their podspec files?

[paulb777]

CocoaPods will union the dependencies from all the requested podspecs in the target of the Podfile, so you can explicitly add 'GTMSessionFetcher/Full', so that all of your targets end up matching the GTMSessionFetcher subspec subset.

[sprynmr]

Aha! I had tried that, and it didn’t work, so I looked closer. Turns out we also had Firebase/Auth required again (which in turn requires just GTMSessionFetcher) in the tests target for some reason. It was already inherited, so it wasn’t needed. Having that there caused the problem to persist. Removing that and adding GTMSessionFetcher/Full to the main Podfile (and the SNG podspec for good measure) fixes the issue.

Thanks for the help!

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[paulb777]

Still an issue and no word from Apple on the radar.

[jlaws]

This is still an issue for us as well

[federicocappelli]

Same here, 3 apps all with the same issue

[VinceBurn]

same problem using Xcode 10.2

[kapoorsahil]

same problem using Xcode 10.3

[darkbit34]

Same error with GTMSessionFetcher using firebase, couldn't I solve it in any way? Are there solutions besides legacy mode? Can someone explain them to me?

I tried to add 'GTMSessionFetcher / Core' to the pod file in both targets but I didn't solve it.

[paulb777]

@darkbit34 See https://github.com/CocoaPods/CocoaPods/issues/8206#issuecomment-484100078 above

[darkbit34]

Let me understand, I have three targets in the pod file, one is the main app one is the test and one is the widget today, I have to remove from the test target "pod 'Firebase'" and insert in the target of the app in the pod file "Pod 'GTMSessioFetcher / Full'"?! without touching the widget today? both the app and today are giving me error! today uses firebase auth.

[ykphuah]

Faced the same issue with GTMAppAuth pulling in AppAuth/Core, and needing codes from AppAuth.

Initial workaround of adding AppAuth above GTMAppAuth in Podfile fails, however, found out that it works after I do the following.

1. Removed all GTMAppAuth from Podfile, run pod install.
2. Add back GTMAppAuth into Podfile, then run pod install again.

[verreliocr]

I faced the same issues too, but I try to add these :

pod 'GTMAppAuth', '1.0.0'
pod 'GTMSessionFetcher/Full', '1.3.0'
pod 'AppAuth', '1.3.0'

in my podfile, and it works...

[vishwas00]

Commenting use_frameworks! in PodFile worked for me.
Using XCode 10.1, pod version 1.8.4

[shinichiro-san]

Hi there,

I have fixes the issue with below code in my case.

platform :ios, '10.0'
use_frameworks!

def google_utilites
  pod 'GoogleUtilities/AppDelegateSwizzler'
  pod 'GoogleUtilities/Environment'
  pod 'GoogleUtilities/ISASwizzler'
  pod 'GoogleUtilities/Logger'
  pod 'GoogleUtilities/MethodSwizzler'
  pod 'GoogleUtilities/NSData+zlib'
  pod 'GoogleUtilities/Network'
  pod 'GoogleUtilities/Reachability'
  pod 'GoogleUtilities/UserDefaults'
  pod 'GTMSessionFetcher'
end

target 'myApp' do

  google_utilites

  pod 'Firebase/Auth'
  pod 'Firebase/Database'
  pod 'Firebase/Storage'
  pod 'Firebase/Analytics'
  pod 'GoogleSignIn'

end

target 'shareExtension' do

  google_utilites

  pod 'Firebase/Auth'
  pod 'Firebase/Database'
  pod 'Firebase/Storage'

end

[sirghi]

Apart for waiting for Apple to fix it, couldn't we just name the produced frameworks differently so there's no name clash? E.g. SDWebImage and SDWebImage-Core (or SDWebImageCore). It's how the target names differ. Why can't the frameworks themselves follow the same convention, I don't get it.

[marcgeeklaberge]

Thank you @shinichiro-san

[wushiyu541]

That works for me, thank you @shinichiro-san

[Nemocdz]

I have the same issue.
Our project has different targets for regions. Share pods with different resources and code in subspecs.
Does anyone have a solution?

[superarts]

Apart for waiting for Apple to fix it, couldn't we just name the produced frameworks differently so there's no name clash? E.g. SDWebImage and SDWebImage-Core (or SDWebImageCore). It's how the target names differ. Why can't the frameworks themselves follow the same convention, I don't get it.

Perhaps if we do have dependencies like Foo/Bar1 and Foo/Bar2, we don't have to have separated binaries, even if they belong to different targets?

[superarts]

For me, it's due to our multi-targets, multi-subspecs system (iOS, watchOS, today extension, siri extension, etc). Something like:

• Utility/Logger/AppDynamics relies on app dynamics, which relies on iOS so it cannot be added to "Watch" target;
• Utility/Logger/FileLogger doesn't have any specific dependencies, and is needed in targets that enables file storing;
• Ulitily/Logger/ConsoleLogger is required by all targets;
• Utility/Core is required by all targets;
• Utility/JailbreakDetection required by iOS target;
• And so on.

Things like this. It works fine for debug build, but we are having problem in archiving.

[rfree18]

I'm having the same issue in our large project. We have our code split up into multiple pods that we import into our main project file. Since we want to share some code with our watchOS and Siri targets, some of our pods have multiple subspecs so we don't have to #if our incompatible code out. Like mentioned above, it builds completely fine for debug but fails on archiving.

[superarts]

I wrote a post about this problem; since we know how CocoaPods works, such behavior is understandable and can be worked around. But it's still good to see a fix here (sorry I'm not able to contribute for now).

[paulb777]

@superarts Thanks for shining light on this issue and I agree that it might be possible to fix CocoaPods to address it. However, it is much more arguably an Xcode bug, in that its intermediate build hierarchy no longer supports multiple versions of the same named framework going to different destinations. This worked fine before version 10.2. There's more detail in the comments above.

[lemanhtien]

Another workaround way is to use Legacy Build System. So far, I can found ways to resolve it

1. Use Legacy Build System
2. If multiple targets depends on multiple subspecs, list all subspecs and shared across all targets
3. Don't use subspecs, create new specs instead.

The problem with these ways

1. Use Legacy Build System ~> Can be removed by Apple in future
2. If multiple targets depends on multiple subspecs, list all subspecs and shared across all targets -> Redundant libraries for other targets, can increase App Size
3. Don't use subspecs, create new specs instead. -> Only work with your specs.

I also feel like it's Xcode bug.

[lemanhtien]

Here's an update from my ongoing investigation:

For subspecs from dynamic frameworks pods, there could have easily been load failures with the old build system depending on which subspec combination got copied into the app's Frameworks folder and which symbols are being used from which targets. For any workspace that ends up with different subspec combinations between an extension and the host app, it should be possible to make it fail at load time by calling methods from subspec combination that didn't get copied to the bundle. Therefore, it is arguable that the new archive failure is a good thing - although it would be much better for the build system to give the error - or at least a warning - in a regular build instead of waiting until archiving to expose it.

For subspecs from static frameworks pods, regular builds with the old and new build systems should always work fine because the right frameworks are built into appropriately labeled directory and properly linked into the right build targets. It doesn't matter which frameworks are copied into the bundle since static frameworks are linked at build time and not needed at load time.

The issue with the new build system is that the archiver wants to put all intermediate frameworks into the same directory instead of separate directories for each build target like the regular builder. I'm thinking about flushing this out a bit further and sending a Radar.

error: Multiple commands produce '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gaeuwroouqpzwlfwgiqtmknxbqjt/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GoogleUtilities.framework':
1) Target 'GoogleUtilities-NSData+zlib' has create directory command with output '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gaeuwroouqpzwlfwgiqtmknxbqjt/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GoogleUtilities.framework'
2) Target 'GoogleUtilities-Environment' has create directory command with output '/Users/paulbeusterien/Library/Developer/Xcode/DerivedData/NewBuild-Extension-Subspec-gaeuwroouqpzwlfwgiqtmknxbqjt/Build/Intermediates.noindex/ArchiveIntermediates/NewBuild-Extension-Subspec/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GoogleUtilities.framework'

Let say we have this Pod file

platform :ios, '9.0'

use_frameworks!

target 'A' do
  pod 'MyUIKit/Button'
end

target 'B' do
  pod 'MyUIKit/Popup'

end

@paulb777 May I ask why Xcode archiver need to create directory command for both MyUIKit/Button and MyUIKit/Popup framework even I only archive target 'A' ? And here target A and target B are not extension targets.

[paulb777]

@lemanhtien I don't think there is a need. That's why I think it's an Xcode bug.

[lemanhtien]

@paulb777 I tried to create 2 framework which has the same name, and embed into 2 different Targets in 1 project. It's still able to Archive successfully.
I'm wondering if the issue comes from Cocopod instead of Xcode 🤔

[IkjotCreates]

Well, I had the same issue
The error is shown below -

Multiple commands produce '/Users/ikjotsingh/Library/Developer/Xcode/DerivedData/ServiceCore-dymywhldzbveayavtkrhbwezaxyt/Build/Intermediates.noindex/ArchiveIntermediates/ServiceCore/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GTMSessionFetcher.framework':
1) Target 'GTMSessionFetcher-Core' has create directory command with output '/Users/ikjotsingh/Library/Developer/Xcode/DerivedData/ServiceCore-dymywhldzbveayavtkrhbwezaxyt/Build/Intermediates.noindex/ArchiveIntermediates/ServiceCore/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GTMSessionFetcher.framework'
2) Target 'GTMSessionFetcher.default-Core' has create directory command with output '/Users/ikjotsingh/Library/Developer/Xcode/DerivedData/ServiceCore-dymywhldzbveayavtkrhbwezaxyt/Build/Intermediates.noindex/ArchiveIntermediates/ServiceCore/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/GTMSessionFetcher.framework'

I have the explanation and reason for this issue.
So GTMSessionFetcher is a depiendency for 2 frameworks i.e Firebase/Performance and GoogleSignIn so XCode creates those dependencies twice without comparing and then gets confused having two commands for exactly same dependency while archiving i.e GTMSessionFetcher
It creates one as GTMSessionFetcher.default-Core and other as GTMSessionFetcher-Core

Solution -

add pod 'GTMSessionFetcher' (dependency which is common between 2 framework) to your main project podfile ;)

I guess by adding this Xcode refer to the main project pod instead of the subSpecs of the frameworks.

[0xMarK]

Hi there,

I have fixes the issue with below code in my case.

platform :ios, '10.0'
use_frameworks!

def google_utilites
  pod 'GoogleUtilities/AppDelegateSwizzler'
  pod 'GoogleUtilities/Environment'
  pod 'GoogleUtilities/ISASwizzler'
  pod 'GoogleUtilities/Logger'
  pod 'GoogleUtilities/MethodSwizzler'
  pod 'GoogleUtilities/NSData+zlib'
  pod 'GoogleUtilities/Network'
  pod 'GoogleUtilities/Reachability'
  pod 'GoogleUtilities/UserDefaults'
  pod 'GTMSessionFetcher'
end

target 'myApp' do

  google_utilites

  pod 'Firebase/Auth'
  pod 'Firebase/Database'
  pod 'Firebase/Storage'
  pod 'Firebase/Analytics'
  pod 'GoogleSignIn'

end

target 'shareExtension' do

  google_utilites

  pod 'Firebase/Auth'
  pod 'Firebase/Database'
  pod 'Firebase/Storage'

end

Thank you @shinichiro-san you've saved me!

What worked for me is:

platform :ios, '12.0'
use_frameworks!
inhibit_all_warnings!

target 'MyProject' do
  pod 'GoogleUtilities'
  pod 'Firebase/Analytics'
  pod 'Firebase/Crashlytics'
  pod 'Firebase/Messaging'
  # Other pods
end

target 'NotificationService' do
  pod 'GoogleUtilities'
  pod 'Firebase/Messaging'
end

[federicocappelli]

So, after reading all the specific solutions proposed above I managed to fix the issue in my special case and I believe that the general rule here is:

For each sub-pod that creates issues, for instance:

Multiple commands produce '/.../iphoneos/my_pod_A.framework':
1) Target 'my_pod_A.common' has create directory command with output '/.../my_pod_A.framework'
2) Target 'my_pod_A.common-SubPodA-SubPodB' has create directory command with output '/.../my_pod_A.framework'

Add an explicit dependency to every target, even if not really needed, like:

pod 'my_pod_A',
pod 'my_pod_A/SubPodA',
pod 'my_pod_A/SubPodB',

This solved the problem for me.

[zhenhuamu]

以上问题，我通过如下方法解决

platform :ios, '10.0'
source 'https://github.com/CocoaPods/Specs.git'

use_frameworks!
inhibit_all_warnings!

abstract_target 'AhakidTarget' do

  pod 'YYModel', '1.0.4'
  pod 'HandyJSON','5.0.2'
  pod 'Kingfisher/SwiftUI', '5.15.7'
  pod 'Moya', '14.0.0'

  target 'Ahakid' do

    pod 'AFNetworking', '4.0.1'

  end

  target 'WidgetExtension' do

    pod 'MBProgressHUD', '1.2.0'

  end

  target 'NotificationService' do

    pod 'JPushExtension', '1.1.2'

  end

end

[参考链接]https://guides.cocoapods.org/using/the-podfile.html

[haofanning]

Same problem here! I use dynamic framework too!

[anupambharti]

So, after reading all the specific solutions proposed above I managed to fix the issue in my special case and I believe that the general rule here is:

For each sub-pod that creates issues, for instance:

Multiple commands produce '/.../iphoneos/my_pod_A.framework':
1) Target 'my_pod_A.common' has create directory command with output '/.../my_pod_A.framework'
2) Target 'my_pod_A.common-SubPodA-SubPodB' has create directory command with output '/.../my_pod_A.framework'

Add an explicit dependency to every target, even if not really needed, like:

pod 'my_pod_A',
pod 'my_pod_A/SubPodA',
pod 'my_pod_A/SubPodB',

This solved the problem for me.

Great Worked for me Thanks