Use third party framework which is embedded in dynamic framework

As i understand the big change from ios dynamic framework and static is that static is linked statically to the code at link time (prior to launch) and dynamic is linked at launch/runtime

Now i have a test project:

  • How to add deleted frameworks again
  • When to use Core Data's NSMainQueueConcurrencyType?
  • What is initWithCoder actually doing when used in conjunction with a core location manager object?
  • iOS 7 Changing UINavigationBar titleView alpha
  • Detecting the direction of PAN gesture in iOS
  • Embedding a framework within a framework (iOS 8+)
  • My project have a dynamic framework linked to it – A.framework.

    import A.framework

    A.framework have a framework embedded inside of it – B.framework

    In my main project i want to use classes from B.framework

    Now i see that with a simple import statement in the main project:

    import B.framework
    

    It actually work and i can use code from inside of the B.framework which is embedded in linked A.framework

    How can it be? is it something that is safe and reliable to use? How does the main project recognize the B.framework?

    What about cases where the main project directly link the B.framework to the project? in this case i see many “duplicate symbol errors” at link time

    Most importantly how can i build A.framework while not embedding B.framework inside of it, while off course using its classes and functions

    Any clarifications will help 🙂

    2 Solutions Collect From Internet About “Use third party framework which is embedded in dynamic framework”

    As you note, linking B.framework would lead to duplicate symbols. This is why A.framework should not embed B.framework. You must never embed a framework in another framework if there is any chance that the consuming application will care about the embedded framework (in practice, this means you really should just never do it).

    A.framework was incorrectly packaged. If you packaged it, you should remove the embedded framework and link everything at the application layer. If someone else packaged it, you should open an issue with them to correct this error. This issue is not new to dynamic frameworks. It was equally a problem with static frameworks. The only appropriate time to link dependencies is at the application layer.

    (There is an exception if you control the entire ecosystem (e.g. Apple). Then things like umbrella frameworks are acceptable. But you’re not Apple.)

    EDIT: It is ok to link, but not embed, a shared framework into another shared framework. The key is that the only copy of the shared framework needs to come from the top-level application. Since that final link step will happen at load, then you won’t have duplicate symbols because there is only one copy of the shared framework. Just don’t embed the sub-framework into yours.

    For example:

    • Create project with framework target
    • Drag in GMA.framework to framework target (this will cause it to link but not embed)
    • Create App target
    • Have app link both GMA.framework and your test framework. This will work fine without collisions because there is only one GMA.framework, and it’s only embedded in the app.

    If you are using multiple framework’s, you can try Cocoa Pods the dependency manager which will help you to access multiple framework. This will also allow you to keep breakpoint which will help you to debug even inside the framework and also you can do changes.