Dyld: Library Not Loaded for a Framework Within a Framework

dyld: Library not loaded for a Framework within a Framework

I contacted Apple with this issue and found a solution to my problem. Apple's Technical support made it clear, that I need to add the FrameworkB.xcodeproj to my application project, so my project structure is:

• FrameworkTest.xcodeproj (the app project)
  
  
  • FrameworkA.xcodeproj (Cocoa Touch Framework)
    
    
    • FrameworkB.xcodeproj (Cocoa Touch Framework)
  • FrameworkB.xcodeproj (Cocoa Touch Framework)

When I have done this the application project can include FrameworkB.framework as an Embedded Library:

This solved my problem and made it possible to run it on an iOS device.

If the build crashes on Release:
Revoke your Enterprise Distribution certificate and create a new one to solve the problem. Once I did that it worked perfectly.

Xcode10 - dyld: Library not loaded for pod installed in 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):

• Runpath Search Paths (LD_RUNPATH_SEARCH_PATHS)
  
  
  • In the example project, these are determined by the cocoapod, but each one is set to $(inherited) @executable_path/Frameworks @loader_path/Frameworks
• Dynamic Library Install Name (LD_DYLIB_INSTALL_NAME)
  
  
  • In the example project, this is unchanged from the default $(DYLIB_INSTALL_NAME_BASE:standardizepath)/$(EXECUTABLE_PATH)
• Dynamic Library Install Name Base (DYLIB_INSTALL_NAME_BASE)
  
  
  • In the example project, set to @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)
...

dyld: Library not loaded: @rpath/Alamofire.framework/Alamofire Referenced from:

Normally you don't have to add the frameworks you installed from your podfile via pod install manually. They are all contained in the Pods framework (in your case Pods_ZSS.framework) and added to your project automatically.

Xcode now tries to add Alamofire.framework a second time and does not find the corresponding header search paths, etc. or does not know, which framework should be used.

Try the following:

Remove the additional import of Alamofire, clean build folder and build again.

If the error still occurs, close Xcode and run pod install via terminal in your project folder. This configures your Pods project and adds the dependencies to your main project for you.

Also check, if the target define in your podfile exactly matches the name of your target in Xcode. E.g. your target in Xcode is named 'SSZ', then your podfile should look something like this:

platform :ios, '<your_target_deployment_version>'

# Imports for target 'SSZ'
target 'SSZ' do

  # Use dynamic frameworks
  use_frameworks!

  # Frameworks
  pod 'Alamofire', '<specified_framework_version>'
  pod '<second_framework>', '<specified_framework_version>'
  pod '<third_framework>', '<specified_framework_version>'
  # so on and on

end

Also remember to open the project's workspace generated after running pod install (<project_name>.xcworkspace). Otherwise Xcode will not build and integrate your frameworks when building your app. <project_name>.xcodeproj just contains your own project without the frameworks.

---

Related Topics