Private pod with static library in along with swift pod

Question

I'm working on pods development for an iOS dev team (on private repo). My low-level C/Obj-C core pod contains a static library with some headers and is used as dependency in other pods (pushed with --use-libraries).

Now that the iOS team wants to integrate Swift pods, they had to add the use_framework! option in the Podfile of their projects. Of course, they obtained the following error during pod install :

The 'XXX' target has transitive dependencies that include static binaries

I spent half a day on the web looking for a way to make my pods compatible with the use_framework! option, in vain. This is very frustrating, as Google Services pods are proofs that it's possible to bypass this problem in a clean way (not with the verify_no_static_framework_transitive_dependencies trick) : the main pod and almost all its dependencies contain static libraries, and everything works perfectly along with Swift pods. Exemple with Google/SignIn which depends on Google/Core (vendored_libraries: Libraries/libGGLCore.a) and GoogleSignIn (vendored_libraries: Libraries/libSignIn.a).

Any idea of what I can do to make my pods compatible with the use_framework! option ?

Thank you all,

Cheers,

Tom

Answer 1

I think I found a hack for my problem. This is quite weird, but I'd say it's clean enough to use it in production ;)

I found it here. The idea is simply to include a source file (even an empty one) in your source_files list inside your podspec.

Basically, the source section of my podspec looks like this :

s.source_files = "myLib/Empty.m", "myLib/Headers/*.h"
s.vendored_libraries  = "myLib/myLib.a"

The only modification I made is to add "myLib/Empty.m" in the source files (Empty.m is strictly empty). Without it, I systematically have the transitive dependencies error when I pod install. With it, pod install works fine. It worked for me with both Cocoapods 0.0.39 and 1.0.0.beta.4.

Well, looks like it's a not so dirty solution, but I'm not sure it'll work in every case. And it's no good news about the cleanliness of Cocoapods...

As I mentionned in comments earlier, Google seems to have found a cleaner solution. So if anybody have an idea of the real clean solution, please share !

Cheers,

Tom

PS : I think I'll name the file DirtyCocoapodHack.m instead of Empty.m, sure they'll love it in the dev team ;)