Cocoapods: Framework targets broken on 1.6.0+ (dyld: Library not loaded)

[BlackWolf]

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

Report

What did you do?

Run pod install on a fresh project that contains an app and a framework target.

What did you expect to happen?

Install all pod dependencies correctly.

What happened instead?

On CocoaPods 1.6.0 and later, the project will compile, but the framework target's pods are not found during runtime, leading to the infamous image not found. On CocoaPods 1.5.3, this works fine.

dyld: Library not loaded: @rpath/Auth0.framework/Auth0
  Referenced from: /Users/user/Library/Developer/Xcode/DerivedData/PodsIssues-czhpwbcfzjbrivdwsqsneyatrgcr/Build/Products/Debug-iphonesimulator/MyFramework.framework/MyFramework
  Reason: image not found

(Auth0 is just an example Pod, this will happen with any Pod)

CocoaPods Environment

Stack

   CocoaPods : 1.7.0.beta.3
        Ruby : ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18]
    RubyGems : 2.5.2.3
        Host : Mac OS X 10.14.3 (18D109)
       Xcode : 10.2 (10E125)
         Git : git version 2.20.1 (Apple Git-117)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib
Repositories : 360dialog - [email protected]:360dialog/d360-cocoapods-specs.git @ 15cf49a1a8b793b260637bbca75e423346cc9661
               master - https://github.com/CocoaPods/Specs.git @ dbce165a85c08fe3d3e6f6d8f430f61e346ca4e3

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-binary      : 0.4.3
cocoapods-deintegrate : 1.0.4
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.3.1
cocoapods-try         : 1.1.0

Podfile

source 'https://github.com/CocoaPods/Specs.git'

workspace 'PodsIssues.xcworkspace'
project 'PodsIssues.xcodeproj'

platform :ios, '10.0'
inhibit_all_warnings!
use_frameworks!

target 'MyFramework' do
    pod 'Auth0'
end

Project that demonstrates the issue

https://ufile.io/5pqin

[Lutzifer]

Is this the same as #8658 ?

[BlackWolf]

I can‘t say for sure if it has the same root cause or not, but I would assume it‘s two different issues. For one, #8658 will fail at compile time with a linker error, while this issue actually results in a compilable project, which will crash at runtime. Secondly, this issue is also happening both from within XCode and when using xcodebuild.

[markltownsend]

I am also having this same issue with a macOS app . I have a main app target, an extension target, and several framework targets. We've had this setup for a while. But recently when trying to update the Podfile and running pod install, I get the above issue that @BlackWolf is talking about. I can't say what version it was working in (I did try and go back to v1.5.3 and it still doesn't work). I also tried v1.7.0 beta 3 or whatever the latest --pre version is and it still doesn't work.

[UberJason]

I'm having this issue with an iOS app as well - I have a main app target, a Today extension target, and one shared framework target. Since Cocoapods 1.6.1, I get the same issue that @BlackWolf is talking about (although interestingly, in my project the issue doesn't appear if the Today widget is absent from the Podfile - it has to be present to trigger the issue). Here's a sample project, if it's helpful.

[markltownsend]

Found a work around for this. If you have a framework target that you and to include a pod for, you MUST also include that pod in either the app target or the extension target. You can't have a pod only referenced in the framework target. This may still be considered a bug, but I got this to work for my solution. I had a framework target that had two pods that weren't defined anywhere else. In the app target -framework.sh shell script, those two pods where removed from the checked in code I had when I did a 'pod install'. When I added those two pods to the extension target, it got added back and all was well with the world again.

[inderdhir]

Any update on this? The workaround won't work for our project because we have multiple framework targets (UI, API etc) and is currently blocking us from updating from v1.5.3.

[markltownsend]

@inderdhir see my comment from 3 days ago.

[BlackWolf]

Just as an update: This bug is still present in 1.7 RC

[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.

[stale[bot]]

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 :+1: