I believe the problem is this section of the generated resource copy script:

https://github.com/CocoaPods/CocoaPods/blob/master/lib/cocoapods/generator/copy_resources_script.rb#L190

Maybe we can get a list of xcassets that are actually part of the target using xcodeproj?

I have the same issue.

I'd just like to add that we started experiencing a crash during the copy pods resources phase. The output from our CI:

[02:46:50]: ▸ Running script 'Copy Pods Resources'
[02:47:04]: ▸ Testing failed:
[02:47:04]: ▸ TDRenditionsDistiller._distill:  Dispatch queue: NSManagedObjectContext 0x7fea0db08dc0
[02:47:04]: ▸ ** TEST FAILED **
[02:47:04]: ▸ The following build commands failed:
[02:47:04]: ▸ PhaseScriptExecution Copy\ Pods\ Resources /Users/distiller/Library/Developer/Xcode/DerivedData/<Redacted>-cgxrnstnbwmdknfkvwpxgpdcqecz/Build/Intermediates/<Redacted>.build/Debug-iphonesimulator/<Redacted>.build/Script-3BF172996E8D8C6785672ED3.sh
[02:47:04]: ▸ (1 failure)

The solution was to comment these lines out from the generated resources.sh scripts:

# Find all other xcassets (this unfortunately includes those of path pods and other targets).
OTHER_XCASSETS=$(find "$PWD" -iname "*.xcassets" -type d)
  while read line; do
    if [[ $line != "${PODS_ROOT}*" ]]; then
      XCASSET_FILES+=("$line")
    fi
  done <<<"$OTHER_XCASSETS"

Then just ensure that the Copy Pods Resources phase happens before the normal Copy Resources phase. This resolved both this issue and the crash. But of course this is a hacky workaround... :)

cc @drico

As a workaround I rename all archives I don't want to "merge" before "[CP] Copy Pods Resources" an rename them back afterwards.

@mfclarke what do you mean by "associated with the target"?

@benasher44 I mean members of the target. For example:

I would expect that Target2 would only have assets from Common.xcassets and Target2.xcassets in the .app bundle. But, it also has the contents of the other xcasset bundles due to the way the cocoapods resources.sh script works.

This is especially troublesome when the names of assets in the individual target xcasset bundles are the same. Since they're all copied into the .app bundle they just overwrite the files in there already and you end up with for example Target3's images in Target1's .app bundle.

Hm okay, so you're saying that these targets have .xcassets that are only added in the main project (i.e. outside of your Podfile/pods), and then the resource copy script (from CocoaPods) is kind of re-bundling all of them together, when it's only meant to be doing it for pods?

Exactly.

The resources.sh specifically searches for all .xcasset bundles outside of the Pods folder and bundles them in. There's probably a good reason for this, but it doesn't play nice if you have multiple targets with different xcasset bundles.

Hm interesting. Thanks for bring this to our attention! This definitely seems like a bug, and we'll try to look into it soon. Of course, we always appreciate PRs, so if you have time/energy to look into this even if it just results in a more detailed analysis of the root cause, we'd appreciate it!

same probleme here when using carthage and cocoapods,it will add assets from the Carthage/Checkouts
I had the problem with facebook/facebook-ios-sdk built using carthage and having assets from FBSDKIntegrationTests included in my app.

Is there any update on this? It increased the build time and my app size significantly. I had to move assets files out of asset catalogs to play nicely.
I think it is very serious bug, if you have large asset catalogs it slows down the build time significantly and it can create issues with assets with the same name in different asset catalog for different targets.

No updates! I'm not sure that anyone is working on this at the moment. It's very likely that this has been an issue for some time, and we'd certainly appreciate anyone's willingness to attempt a PR to fix!

We currently use this https://github.com/2359media/ios-dev-discussions/issues/7 workaround.

@almsta @Tibbs are we sure this is not "fixed" by cleaning the derived data folder? Perhaps the assets of the first target built still remain in the derived data and end up there?

I am looking into this btw.

Also wonder if this is fixed by #6694

@dnkoutso since the assets are compiled every time, cleaning the derived data does not work, imo. Did not try #6694

@almsta, @mfclarke I know this is a very old issue but would love to resurface it. Does anyone have a sample app to use to repro this?

I don't think it was fixed, I just stopped using asset catalogs as a whole.

Hey @dnkoutso, in our case all our xcasset bundles contain assets with the same names (just different image content). So in the end the fix for us was ensuring [CP] Copy Pods Resources happens before the regular Copy Bundle Resources phase, so the correct ones overwrite whatever ones cocoapods has copied in already.

I don't have a sample app handy sorry.

Confirm still having this issue. CocoaPods 1.4.0

@almsta your link to a workaround does not work, can you explain the idea behind?

@appmagnetics the mentioned linked contained the following, added to your Podfile:

post_install do |installer_representation|
    # Pods-<target>-resources.sh to only handle target specific xcassert files.
    # orignal workaround found here: https://github.com/2359media/ios-dev-discussions/issues/7
    installer_representation.aggregate_targets.each do |at|
        files = at.user_targets.map{|t|
            t.resources_build_phase.files_references.select{|f|
                f.last_known_file_type == 'folder.assetcatalog'
            }.map{|f|
                Pathname.new(f.real_path).relative_path_from(f.project.path.dirname)
            }
        }.flatten
        script = at.copy_resources_script_path
        files = files.join('" "')
        `sed -i '' 's@OTHER_XCASSETS=.*@XCASSET_FILES+=(\"#{files}\")@' '#{script}'`
    end
end

@almsta thanks a lot. Can you explain a bit what happens in your code snippet? You are running copy resources script with the explicit list of files? But what happens with the original copy files script which is installed by CocoaPods - will they get overwritten?

@almsta I've compared the original and "fixed" script and I see how it works now, thanks!

Definitely a bug. See more here #7779 (comment)

It appears the link to the previous workaround is dead and the workaround posted above does not work for recent version of CocoaPods due to changes in the script.

I have updated the workaround to support the script changes since my team still deals with this issue:

post_install do |installer_representation|
    installer_representation.aggregate_targets.each do |at|
        files = at.user_targets.map{|t|
            t.resources_build_phase.files_references.select{|f|
                f.last_known_file_type == 'folder.assetcatalog'
            }.map{|f|
                Pathname.new(f.real_path).relative_path_from(f.project.path.dirname)
            }
        }.flatten
        script = at.copy_resources_script_path
        files = files.join('\\\\\n')
        `sed -i '' "s@OTHER_XCASSETS=.*@OTHER_XCASSETS=$\'#{files}\'@" '#{script}'`
    end
end

Superseded by #8431. This is a 2 year old issue and it is still an issue but #8431 is newer with more info and a sample.