iOS框架：在拥有其他第三方库时，如何更好地实现这一目标？

Question

Cross-posting from here, from the issue I created on the github project jverkoey/iOS-Framework . It seems to get you 90% of the way, in regards to making a nice .framework for iOS to distribute to third-parties.

But what if you're distributing other third-party SDKs in your .framework? Is there a way to include .a, .framework, and other .dylib files that these other third-party SDKs have, directly into your .framework?

Is it possible to have other third-party frameworks wrapped by the framework that you create, as outlined in this project that may have things like:

• .a files
• other .framework files
• other .dylib files

So that devs using your framework, wouldn't have to manually add .a, .framework, and .dylib files from the third-party libraries your framework wraps?

I'd love to be schooled in why this is not possible, if so, for each of those files.

---

Resources:

• https://stackoverflow.com/a/4733885/5716 regarding .dylib files is true?
• https://stackoverflow.com/a/8170851/5716 regarding .a files, possible? Sane?
• ObjC: How to compile static library that includes optional classes that depend on a third party library regarding other static libraries in yours, ugh

(via https://github.com/jverkoey/iOS-Framework/issues/67 )

Answer 1

I would say it's not recommended to embed other frameworks/libraries. It can cause issues and it bloats the framework. Look at what Apple does, when you need a library/framework you add it.

When you publish a framework, just state (website/readme/github) what it depends on (ie CoreLocation.framework, CoreGraphics.framework, etc). If open source, you might need to state a specific version that your framework works with.

I've had tons of headaches from 3rd party libraries/frameworks that had an embedded source code dependency (Amazon caused my app to fail to build with their iOS AWS SDK and SBJSON inner dependency).

NOTE If you do include 3rd party source in your build, you need to make sure you rename all the code files (ie SourceFile.h > PSSourceFile.h, etc). Otherwise people will not be able to integrate your .framework if they already have the source in their project. They'll get duplicate symbols, and their only solution is to either: not use your framework or rename their files to prevent duplicate symbols (I had to manually rename a ton of files from the IOS AWS SDK before they fixed the issue).

Answer 2

First off, iOS does not support the creation dynamical libraries. The only dynamic libraries that can be used by iOS are those already included within code for iOS projects. This is due to the nature of how iOS handles dynamic libraries and allows them to be shared across applications. Since a library that you link should not be shared across applications, they restrict this.

This leaves us with static libraries. In iOS there are two ways to package a static library. The first is by just creating the .a and setting the headers. The other is to create a .framework package that just organizes the static archive and the headers in a format that's easy to handle by the system.

With that in mind a static library is just a collection of compiled source objects .o files in a .a archive. These have not been linked and the symbols have not been created for them. From my understanding this is why header location is important and in particular which headers are public, protected and private.

There are reasons that you might not want to bundle static libraries into another static library. If you have two libraries that both contain a dependent static library then you will run into conflicts that can cause a lot of issues. The third link you posted talks about this.

Now if you don't care about the problems that are going to arise by two libraries both including the same static library dependency, the way you would go about this is by combining the two libraries together. I have not tested this but I believe you can do it multiple ways. I will modify this post after I test. The tools would be:

libtool which in the end would just lipo the two together

lipo which combines two static libraries (mostly in the creation of architecture specific fat binaries)

ar which you would use to e(x)tract the .o files from both .a archives and then archive them back together into one binary.

You would need to include the headers for both archives in your header search paths for either of these methods to gain public access to them outside of your project and I'm not 100% on how your framework compiles with dependencies on these joined libraries but I am creating a test project to see.

Other than all of that, including the source of another library and building it into your library instead of its own separate library is one way to go about it too.