Static library with cocoapod dependency: define in Podspec s.dependency, subpixel or both?
I am converting a static library that we use internally to CocoaPod so that our host applications can simply pull it out by specifying it in their subfiles. This static library, in turn, depends on a third party Pod called HockeySDK.
In my Podspec static library, I specify the HockeySDK dependency as follows:
# MyStaticLib requires the latest HockeySDK framework:
s.dependency "HockeySDK", "3.6.4"
I also specify the dependency in a subfile which is in the root of my static library:
target "MyStaticLib" do
pod "HockeySDK", "3.6.4"
This seems to work well - if I reference MyStaticLib in the MyApp subfile, it pulls in MyStaticLib and also magically pulls in the HockeySDK dependency, which is all good in the world.
What is the difference between these two seemingly redundant mechanisms for specifying a HockeySDK dependency? Why should I use one or not the other or both?
source to share
The first script is used to indicate that your library has a runtime (as well as a compile time, because in cocoapods essentially all runtime is also compile-time dependent) from the HockeySDK.
The second scenario says that your goal depends on the HockeySDK to build.
The difference is quite subtle, but more obvious if you don't statically bind. Since you are linking statically, compile time and runtime are the same thing (which means the second scenario is the same as the first).
If you dynamically linked with the HockeySDK, then it is necessary for the host application to be notified of this so that it can provide the dependent library when linking the library. The way to do this is to distribute the dependency via podspec.
In the podfile, you declare 1. the target and 2. you need the object file as well as the headers from the HockeySDK to compile the target. This only affects the creation of your own library. The people consuming your library are using a BOM, not a subfile.
source to share