Xcode New Build System CocoaPods "Copy Pods Resources" has Assets.car in Output Files and conflict with "Copy Bundle Resources"
Asked Answered
H

3

7

We are using new build system and Cocoapods 1.7.5 for our Xcode project. Our project (let's call it Y) is actually a development pod, but we also have written some codes to create an application demo (you know, to make builds faster and iterations quicker). These demo codes (AppDelegate.swift, launch tasks etc.) are not included in the development pod. The remaining ~90 percent of the source codes and resource files (such as i18n strings and image resources) get packed into the development pod for another project (let's call it X) to use.

While developing, most of the changes occur to the dev pod part of Y, so we need to make sure that every slice of change is included when X does pod install.

Recently we encountered a problem:

error: Multiple commands produce '/Users/x/Library/Developer/Xcode/DerivedData/Y-cawteybtitmeiafweribgqzkuhnr/Build/Products/Debug-iphoneos/Y.app/Assets.car':
1) Target 'Y' (project 'Y') has compile command with input '/Users/name/DEV/workspace/Y/SupportFiles/Assets.xcassets'
2) That command depends on command in Target 'Y' (project 'Y'): script phase “[CP] Copy Pods Resources”

After hours of searching multiple commands produce assets.car on Google, we finally saw a plausible explanation:

*.xcassets of Copy Bundle Resources --> Assets.car

*.xcassets of [CP] Copy Pods Resource --> other Assets.car

The first one covers second in the New Build System,That's the reason.

When we manually remove the ${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/Assets.car from output files of [CP] Copy Pods Resource, the error is gone and everything works fine. However, whenever we git checkout to another branch, or pod install, or pod update, there is a pretty high chance that the ${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/Assets.car appears again in the output files of [CP] Copy Pods Resource. We need to manually remove it again and again, which is tedious and frustrating.

Then we started to question: Who is behind all this? Who is responsible for adding ${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/Assets.car to the output files of [CP] Copy Pods Resource? We focused our sight onto Y.podspec and found these lines:

  s.resource_bundles = {
    'Y' => ['Resources/*'], # assets, lottie etc.
    'YAuto' => ['auto_resources/*'] # i18n strings etc.
  }

We thought we were using resource_bundles wrong, so we looked it up, again on Google. Surprisingly, using resource_bundles over resources is recommended by official documentation. Additionally, we couldn't find any inappropriate usage in terms of resource_bundles, leaving us out of options.

Can somebody help? I was thinking maybe we could patch Y.xcworkspace in the post_install script in Podfile, but I don't know how.

Him answered 19/11, 2019 at 7:33 Comment(3)
maybe related to github.com/CocoaPods/CocoaPods/issues/8431Candelabra
Unfortunately, none of the solutions proposed in your link has successfully addressed my problem. Thanks anyway!Him
Related post with some workarounds: dev.to/kylefoo/…Chestnut
H
2

It's been nearly a month and here is an update. Turned out that this problem was caused by a misuse of another development pod of Y. We forgot to use resource_bundles in the Podspec of that dev pod, which leaded to the resources of that dev pod NOT been packed into a .bundle file, followed by [CP] Copy Pods Resources explicitly adding an xcassets into the input files, colliding with the other one in the Copy Bundle Resources.

Him answered 17/12, 2019 at 10:33 Comment(1)
hi using resouce_bundles i can not retrieve image assets with Xcode 12.5. There is always Assets.carin Pod.bundle, can not retrieve image assetsCocteau
H
5

I resolved this issue by writing a post_install script in Podfile which automatically deletes these Assets.car.

post_install do |installer|
    project_path = 'Y.xcodeproj'
    project = Xcodeproj::Project.open(project_path)
    project.targets.each do |target|
        build_phase = target.build_phases.find { |bp| bp.display_name == '[CP] Copy Pods Resources' }
        assets_path = '${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/Assets.car'
        if build_phase.present? && build_phase.output_paths.include?(assets_path) == true
            build_phase.output_paths.delete(assets_path)
        end
    end
    project.save(project_path)
end

It seems to be a CocoaPods bug that still has not been fixed by now.

Him answered 20/11, 2019 at 9:51 Comment(3)
Got undefined method 'include'? for nil:NilClass for build_phase.output_paths.include?Antitoxin
You may need to add require 'xcodeproj' to the top of your PodfileHim
Thanks for the answer and clarification. I actually solved it by just running pod update. The problem probably lied in an older version of one of the many frameworks we're using.Antitoxin
M
4

This issue comes about in many ways; some like the described problem above and other times for having a Share Extension or Watch app in addition to an iOS app. In all scenarios, it's caused by there being multiple Assets.car outputs in the [CP] Copy Pods Resources of those targets which create duplicate Assets.car files. The compiler obviously doesn't know how to handle that, so we shouldn't be allowing CocoaPods to generate multiple output files with the same name.

The recommended solution per the CocoaPods issue is to put this in your Podfile:

# Default platform for most targets
platform :ios, '11.0'

# Workaround duplicate Assets.car issue https://github.com/CocoaPods/CocoaPods/issues/8122
# This impacts the new Xcode build system
install! 'cocoapods', :disable_input_output_paths => true

Xcode 12 also fixes an accompanying issue that let to build performance issues when using the new build system with this workaround. The legacy build system is officially deprecated as of Xcode 12.

Michikomichon answered 26/8, 2020 at 14:43 Comment(1)
After spending 4 hours this, this was the answer and fixed the issue.. Thank you.Baud
H
2

It's been nearly a month and here is an update. Turned out that this problem was caused by a misuse of another development pod of Y. We forgot to use resource_bundles in the Podspec of that dev pod, which leaded to the resources of that dev pod NOT been packed into a .bundle file, followed by [CP] Copy Pods Resources explicitly adding an xcassets into the input files, colliding with the other one in the Copy Bundle Resources.

Him answered 17/12, 2019 at 10:33 Comment(1)
hi using resouce_bundles i can not retrieve image assets with Xcode 12.5. There is always Assets.carin Pod.bundle, can not retrieve image assetsCocteau

© 2022 - 2025 — McMap. All rights reserved.