Private pod with static library along with fast container

Question

I am working on developing pods for the iOS development team (on a private repo). My low-level C / Obj-C core contains a static library with some headers and is used as a dependency in other modules (clicked with --use-libraries ).

Now that the iOS team wants to integrate Swift modules, they must add the use_framework! parameter use_framework! into the subfile of your projects. Of course, during pod install they got the following error:

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

I spent half a day on the Internet trying to find a way to make my modules compatible with the use_framework! option use_framework! in vain. This is very frustrating because the Google Services routines are proof that you can get around this problem in a clean way (not with the verify_no_static_framework_transitive_dependencies trick): the main unit and almost all of its dependencies contain static libraries, and everything works fine together with Quick Pods. An example of Google / SignIn , which depends on Google / Core (vendored_libraries: Libraries / libGGLCore.a) and GoogleSignIn (vendored_libraries: Libraries / libSignIn.a).

Any idea what I can do to make my modules compatible with use_framework! option use_framework! ?

Thanks everyone

Greetings

Tom

Answer 1

I think I found a hacked problem. This is rather strange, but I would say that it is clean enough to use it in production;)

I found here . The idea is to include the source file (even empty) in your list of source files inside your podspec.

Basically the original part of my podspec looks like this:

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

The only thing I did was add "myLib / Empty.m" to the source files (Empty.m is strictly empty). Without it, I systematically get a transient error when installing pod. Using it, installing pod works great. It worked for me with both Cocoapods 0.0.39 and 1.0.0.b.4.

Well, it doesn't seem like a dirty decision, but I'm not sure if it will work in every case. And there is no good news about the purity of Cocoapods ...

As I mentioned earlier in the comments, Google seems to have found a cleaner solution. Therefore, if anyone has an idea of ​​a real clean solution, please share!

Greetings

Tom

PS: I think I will name the file DirtyCocoapodHack.m instead of Empty.m, I'm sure they will like the dev command;)