I can add that as a workaround I just reordered the build steps so that the cocoa pods resources gets copied before the standard xcode build step. That way I get my target dependent resources copied last.

That’s very unfortunate. Are you even using pods that have asset catalogs?

@ulrikdamm Any ideas on how to improve this?

If there is a way to read what files are copied in the copy bundle resources build step, then we could just pick those asset catalogs when building our own. Right now it just looks for xcassets files in the source directory.

Hmm, that’s probably going to be complex. I’ll have to mull this over.

Also seeing this with a similar project setup, and appreciate how hard it is to fix. If you need an example project or any more info, then I'd be happy to send something over.

Same issue here.

Facing the same issue. Has there been a resolution yet on this issue.

Alas not. I think one of you (or others with the same issue) will have to sit down and spend some time playing with Xcode to see if you can find a pragmatic solution that works regardless of CocoaPods.

I am having the same issue. Our current solution has been to delete the .xcasset folder that belongs to any target we are not building for.

I've poking around in the copy resource script and found that the .xcassets part in install_resource() was empty.
I guess it should be handled in that function instead of just copying all files. I'll have a look tonight.

I posted about this problem on my blog, though I did not know it was related to CocoaPods until a commenter pointed it out. He also included a possible solution :) Even though it won't work in my case due to some of the pods having xcassets in them, it may get this bug fix on the right track.

http://matt.coneybeare.me/using-xcode-asset-catalogs-with-multiple-targets/#comment-1213336157

I'm also having this issue. None of the pods I use have any extra xcassets in them. How hard would it be to modify the copy_resources_script.rb so that when it checked if there were any xcassets it only checked if there were xcassets within the pod projects. Then at least for people who dont have pods that include extra xcassets it won't mess up their build. Something as simple as changing this line

if [[ -n "${WRAPPER_EXTENSION}" ]] && [ `xcrun --find actool` ] && [ `find . -name '*.xcassets' | wc -l` -ne 0 ]```

to this

if [[ -n "${WRAPPER_EXTENSION}" ]] && [ `xcrun --find actool` ] && [ `find Pods -name '*.xcassets' | wc -l` -ne 0 ]

I'm having the same problem on my current project. The project is being built continuously by a jenkins server that cleans the directory and runs pod install on every build, so a more durable solution than editing the Pods-resources.sh script would be preferred.

For those having this issue, and having do delete the same lines everytime you pod install, I created a build phase run script that does it automatically, by using sed.

The lines that the script removes are the ones shown in here.

Go to your build phases, Editor>Add Build Phase>Add Run Script Build Phase.
Paste in the following code:

# Backup the original file
if [ ! -f Pods/Pods-resources.sh.bak ];
then
    cp Pods/Pods-resources.sh Pods/Pods-resources.sh.bak
fi

sed '/if \[\[ -n "\${WRAPPER_EXTENSION}" ]] \&\& \[ `xcrun --find actool` \] \&\& \[ `find \. -name '\''\*\.xcassets'\'' \| wc -l` -ne 0 \]/,/fi\n/d' Pods/Pods-resources.sh > Pods/Pods-resources.sh.temp
sed '/*.xcassets)/,/;;/d' Pods/Pods-resources.sh.temp > Pods/Pods-resources.sh
rm Pods/Pods-resources.sh.temp

Important: Move your script above the existing Copy Pods Resources.

This can probably be made shorter by piping the results, but meh.

I just tried out @barksten's workaround. In my particular case, I reordered the "Copy Pods Resources" build phase to occur right before the "Copy Bundle Resources" build phase. The resulting workaround works quite well without having to delete sections of the Pod-resources.sh script file.

Issue has been confirmed by @neonichu

I'm having this issue also.

Another workaround based on @rfsbraz idea. I've basically added @rfsbraz script to my post_install hook. My ruby is pretty basic so I'm just calling the script from ruby. I've also simplified the sed regexes a bit so they are a bit more readable. It might be worth putting into it's own script, but I like having it all contained in the podfile.

I like this because it isn't run everytime you build and automatically removes this for all targets.

post_install do |installer|
  installer.project.targets.each do |target|
    %x~ if [ ! -f Pods/#{target.name}-resources.sh.bak ]; then cp Pods/#{target.name}-resources.sh Pods/#{target.name}-resources.sh.bak; fi ~

    %x~ sed '/WRAPPER_EXTENSION/,/fi\\n/d' Pods/#{target.name}-resources.sh > Pods/#{target.name}-resources.sh.temp ~
    %x~ sed '/*.xcassets)/,/;;/d' Pods/#{target.name}-resources.sh.temp > Pods/#{target.name}-resources.sh ~
    %x~ rm Pods/#{target.name}-resources.sh.temp ~
  end
end

Is pull request #2212 sufficient to fix this? It fixes the issue for my own project, but I could be overlooking something.

I have the same issue

I have the same issue. The project has xcassets. None of the pods have xcassets. I don't get this error building the main target. Instead, I get it building the test target.

@rfsbraz 's solution works as a temporary workaround

I was just bitten by this last night too while re-organizing our project to make better use of xcassets. After several hours of confusion and frustration mis-directed at Xcode, googling finally led me to @coneybeare's blog post from which I found this issue. I've successfully implemented @rfsbraz's workaround in the interim, and look forward to this being properly fixed in CocoaPods.

Thank you all for documenting and diagnosing the problem!

@AliSoftware Your branch seemed to fix our issues. Do you expect it to go into, say, a 0.36.4 release?

@AliSoftware I may have spoke too soon, actually. It looks like running pod install using your branch results in a new duplicate reference to my .xcdatamodeld file being added to the Xcode project each time.

@irace You mean that the first time you run pod install you got your pod's .xcdatamodel file added and present only once, but if you re-run pod install you got it added again?

@AliSoftware That seems to be the case, yes.

Any news on this? Can't run the project properly without to do clean before. I tried to use the fix proposed by @T-Pham but I'm not sure if I set it correctly. Maybe something is wrong with my project path.

Considering the commit message that closed this, should this issue be reopened until a fix is confirmed?

None of the scripts seem to be working for me. I am meant to be uploading an app to Apple today but the iPad target ignores its assets folder so has no app icon.

Is there an updated Cocoapods version that has this fix in?

Is someone have any news? Can't use pods because of this bug.

Same error for me

You're welcome to test and see if master fixes your problem, https://github.com/CocoaPods/guides.cocoapods.org/blob/gemfile/source/using/a-gemfile.html.md

A bit of update: We will provide a fix in an upcoming release, that won't properly fix this #1546 (white-label apps, a.k.a multiple xcassets in various targets in the user's project), but that will fix cases for pods with xcassets.

The matter at hand with the current 1546 issue is way more complex that we first imagined, and will require a more complex approach. I already tried a bunch of ideas in the past month, sadly those refactoring and trials failed to cover every use case, so we still need to decide which way we'll be going from there to fix 1546 with a better, proper solution.

Is swapping the build phase order still a reliable fix? Does the order get reset when pod install is run?

This wasn't meant to be closed.

So it looks like 0.36.4 fixed the issue for me for using Watch Extension and CocoaPods.

Still having this issue in 0.37.1. Fixed it reordering the build phases and adding @T-Pham 's script phase: find ${PROJECT_DIR} -name "*.xcassets" -exec touch {} \+; before the Copy Bundle Resources phase

Used to be an issue previously but hasn't been an issue since upgrading to 0.37.1 (was on 0.34 previously with a manual workaround to the Pods-resources.sh file)

My work was abandoned because it couldn't work at all with
configuration-dependent pods so didn't fit all the cases
Le mer. 9 sept. 2015 à 22:40, Rafael Nobre notifications@github.com a
écrit :

@AliSoftware https://github.com/AliSoftware any news on this? Your
approach looked fine as actool should only try to compile user assets with
the right target ownership. I have a white-label project idea stalled
because of this one, I may contribute a sample project of my use case if
you need it.

—
Reply to this email directly or view it on GitHub
#1546 (comment)
.

I see. I realized that your efforts tried to fix assets coming from Pods, while the issue with multiple assets in user targets being broken is just a side effect of the current pods-resources script, am I right on these conclusions? What would be the simplest work-around to allow this white label use case to work?

I have run into the same problem. In our project we need to support all of these:

1. shared user asset catalogs
2. per-target user asset catalos
3. pods with asset catalogs

I ended up fudging the resource script from Podfile post-install hook.

The downside is that you have to re-run pod install if application's asset catalogs are added or removed. But it almost never happens in our case (YMMV). Pods asset catalogs change more often, so I've put it in the post-install hook, as opposed to a standalone script. It's dirty but it works.

This issue has been inactive for a long time and will be closed because we want to move forward with a clean slate after our 1.0 release. If you believe this is still relevant, please retest with the 1.0 release candidate and comment with a reproducible project in order for this to become actionable again. Thanks!

Same error in pod 1.7.5.
I tested and found is cocoapods.
a coment in Pods-{{TARGET}}-resources.sh

# Find all other xcassets (this unfortunately includes those of path pods and other targets).

What is the solution?