I have a project with target frameworks.
FrameworkA is the only one to use a certain pod, hence in my pod file I h
At first, check whether your CocoaPod is compatible (supported) or not
.
Make sure you dragged FrameworkA
to the Embedded Binaries
section in your project's General settings tab. Also make sure you have Embed Frameworks (1 item)
in Build Phases tab and FrameworkA
is included there.
Here's a solution:
Step One: Drag and drop FrameworkA.framework
in your project navigation. Link framework and Library added this library.
Step Two: In Xcode go to Project > General > Embedded Binary > Add FrameworkA.framework
.
Step Three: Make sure that in Build Phases tab Link Binary with Libraries (1 item)
and Embed Frameworks (1 item)
do exist.
P.S. I did it in Xcode 10.2.1 but in Xcode 10.1 it works the same way.
This problem is just on iOS 13.3.1.
You can't fix it, Just you have to downgrade to iOS 13.3 or wait for Xcode new update.
I too was facing the same problem. All you need to do is set the third party frameworks you are using for e.g:- PodA as Optional instead of Required under Link binary with Libraries in build Phases section. That's all. try it again and it will run as expected.
Note:- You need to add the PodA in the app in which you are using your framework. There is no other way except create a static framework consisting your PodA and use this newly created static framework inside your dynamic framework.
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)
...
The reason the build succeeds is that the PodA
framework is visible to the FrameworkA
during compilation (it can link to it), but when the application launches, then it tries to find and load the dynamic framework PodA
required by the FrameworkA
, and it looks like the PodA
is not embedded in the MainAppTarget
, so the app crashes with the error message you saw.
To fix this, make sure that the PodA
framework is embedded in the MainAppTarget
. Specifically, you need to make sure that the final app bundle contains the PodA.framework
in the Framewokrs
subfolder. Usually cocoapods copies the frameworks automatically.
Check that the Build Phases for the MainAppTarget
contains cocoapods's [CP] Embed Pods Frameworks
and that the scripts' input files contain the path to the PodA
framework. Something like this (example shows Alamofire pod):
I have set up a project with the details you posted, but it looks to me that cocoapods handles this case automatically in the created workspace setup (you can take a look at my demo project here: https://github.com/DmitryBespalov/StackOverflowPodFramework). If your setup is different, please let me know of the details and I can help you further with that.
You have to add pod 'PodA' in FrameworkA target into MainAppTarget also.
target 'MainAppTarget' do
pod 'PodA'
end
target 'FrameworkA' do
pod 'PodA'
end