I have a project with target frameworks.
FrameworkA is the only one to use a certain pod, hence in my pod file I have something like
target 'MainAppTarget' do
...
end
target 'FrameworkA' do
pod 'PodA'
end
the build succeeds with no problem, but when I run the app on a simulator the app crashes immediately with the following error message:
dyld: Library not loaded: @rpath/PodA.framework/PodA
Referenced from: .../Build/Products/Development-iphonesimulator/FrameworkA.framework/FrameworkA
Reason: image not found
I tried all the usual suspects (delete derived data, clean, pod deintegrate...) nothing worked so far.
Any idea why this would happen, and how I can make it work without having to install all the pods necessarily on both targets?
The app is in Swift 4.2.
From your error message, there are a few things that should be checked.
dyld: Library not loaded: @rpath/PodA.framework/PodA Referenced from: .../Build/Products/Development-iphonesimulator/FrameworkA.framework/FrameworkA Reason: image not found
The first thing that seems odd is that the path for the framework that is being loaded (FrameworkA.framework) is not embedded inside an app. Check the "General" tab of the MainAppTarget and make sure the framework is appearing in the "Embedded Binaries" and "Linked Frameworks and Libraries" sections.
Second, @rpath
is a shorthand for the runpath
search path list, which tells dyld
where to look for needed libraries.
Here's an example project on Github with a main app that uses one Cocoapod, and a dynamic framework that the main app depends on that uses a different Cocoapod: https://github.com/dtweston/FrameworkPodTest
Build settings that you should check on all of the targets that are involved (including the framework targets built by the Pods project):
LD_RUNPATH_SEARCH_PATHS
)
$(inherited) @executable_path/Frameworks @loader_path/Frameworks
LD_DYLIB_INSTALL_NAME
)
$(DYLIB_INSTALL_NAME_BASE:standardizepath)/$(EXECUTABLE_PATH)
DYLIB_INSTALL_NAME_BASE
)
@rpath
(again determined by the Cocoapod)Here's a screenshot of the built application bundle showing how it's laid out:
You can use otool
to get information about how the application is assembled by xcodebuild.
Here's the main app binary:
otool -L FrameworkPodTest
FrameworkPodTest:
@rpath/KeychainSwift.framework/KeychainSwift (compatibility version 1.0.0, current version 1.0.0)
@rpath/Lottie.framework/Lottie (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/UIKit.framework/UIKit (compatibility version 1.0.0, current version 61000.0.0)
@rpath/Framework.framework/Framework (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1560.10.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics (compatibility version 64.0.0, current version 1245.9.2)
...
And the framework binary:
otool -L Frameworks/Framework.framework/Framework
Frameworks/Framework.framework/Framework:
@rpath/Framework.framework/Framework (compatibility version 1.0.0, current version 1.0.0)
@rpath/KeychainSwift.framework/KeychainSwift (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1560.10.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
@rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1000.11.42)
@rpath/libswiftCoreFoundation.dylib (compatibility version 1.0.0, current version 1000.11.42)
...