Include Libraries in iOS Library Project
I am writing an iOS library that depends on some other open source libraries. Apparently it is not possible to have two classes with the same name, so it is possible to compile a library and a project that could potentially use it compiles as well, but they don't work well (at link time).
The library is aimed at a large audience, so I cannot make any assumptions about whether these developers will import the same libraries or not, or if they might be using another incompatible version of the same libraries.
I have been looking around but cannot find a clear solution to my problem (maybe not). While I'm thinking about these options:
- Inform users that the X libraries are already included in the project, so they do not include them either. This means that they cannot use a different version of the X libraries.
- As an improved version of the former, use CocoaPods so dependencies are resolved automatically. Still has the disadvantage that the two versions of the library cannot coexist.
- Import and rename all classes that my library depends on, prefix them so the names don't conflict with the original ones. This is a tedious job, but more importantly, it has the disadvantage that I would not be able to pull / push the code from / to the original library as the code changed too much. It still seems to me the best option from a user point of view.
Can you think of a better idea? I am new to library projects, so maybe there is something obvious that I am not seeing.
We still haven't decided whether to distribute in binary or source form. If there is a reason to choose one or the other, I would also like to hear your opinion.
source to share
When I faced this problem, I chose the third option and prefix the dependent classes in my library. The reason you might want to consider this rather than relying on the user to import others would be because you can guarantee compatibility and you don't have to worry about the versions of whoever you depend on.
source to share
The first point is
Tell users that X libraries are already included in the project, so they don't include them either
so you have the static library Foolib.a , it has a third party dependency Barlib.a , in order for Foolib to be created, Foolib HEADER_SEARCH_PATHS
must be installed in the Barlib public headers path. No more.
If you distribute source code you can use CocoaPods (that's a good way to go), or you can add the Barlib repository as a git submodule (or whatever for your VCS choice) of your repository and put the code HEADER_SEARCH_PATHS
in that path or you can require your user grabbed their own Barlib and manually edited HEADER_SEARCH_PATHS
to the correct path (if you send CocoaPods or submodule route, user can do it easily, more options).
Nothing from Barlib is included in your project.
On the other hand, if you distribute a binary for your user to link to your application, you must indicate in your instructions that Foolib requires Barlib to be bound to the application. Instructions on how to get hold of Barlib would be nice.
Nothing from Barlib is included in your project or compiled into your library.
Second point -
use CocoaPods so dependencies are resolved automatically. Still the disadvantage that the two versions of the library cannot coexist
Two versions of the same library in the same application is not possible, but a situation where the end user already requires Barlib 3.0 wants to use your Foolib, but Foolib requires Barlib 4.0 to never come up - it depends if you are a developer. You can be generous and support multiple versions of Barlib (i.e., for Foolib to work, you need to work with Barlib1.0, Barlib2.0, Barlib3.0 OR Barlib4.0 associated with an app, like writing an app that supports iOS5 and iOS6) or , you may be cocky and need a specific version, and if the user already needs a different version of Barlib, it will be difficult for you to change your code if they want to use your library.
Third point -
Import and rename all classes that my library depends on, prefix them so the names do not conflict with the original
It's too scary for me now. Unfortunately.
Nothing from Barlib is ever "in your" project or compiled into your library. You are not distributing any copy of Barlib - either bundled in your binary or as source.
source to share