Why does the Swift version of LibSignalClient require use_frameworks! and not support static .a when used via CocoaPods?

[Sherlockzms]

Hi Signal team,

Thank you for providing the Swift wrapper for LibSignalClient. I’m currently trying to integrate it into an iOS project using CocoaPods.

In my setup, I prefer to keep most dependencies as static libraries (.a), and avoid using use_frameworks! in the Podfile to reduce binary size and build complexity. However, I’ve found that LibSignalClient does not seem to support being consumed as a static library when used via CocoaPods. Specifically:
• If I do not enable use_frameworks!, the build fails with the error:
ld: warning: Could not find or use auto-linked library 'signal_ffi': library 'signal_ffi' not found

•	If I enable use_frameworks!, it builds and links correctly, but this causes all other pods to be built as dynamic frameworks, which is not ideal in my project.

I’ve also attempted to wrap the prebuilt libsignal_ffi.a as a development pod (using vendored_libraries, module.modulemap, etc.), but linking still fails unless use_frameworks! is enabled.

My question is:
Why does the current CocoaPods setup for LibSignalClient require use_frameworks! and dynamic linking?
Would it be possible to support static library usage (.a) as well, especially for users who integrate LibSignalClient via path-based local pods and want to avoid dynamic frameworks?

Any guidance or explanation would be greatly appreciated.
Thanks again for the great work on Signal!

Best regards

[jrose-signal]

It's mostly just that it isn't what we use—LibSignalClient is used from multiple binaries in the iOS app (the app and two extensions), so having it in .a form would naively result in it being included multiple times in the app download. Of course linker settings could potentially address this (i.e. re-exporting from a common framework higher up in the dependency graph) but for now it works for us. There's definitely added trickiness with the Rust part of the library built separately.

We'd be open to taking patches to change this, as long as it isn't an undue maintenance burden, but we don't have any plans to generalize the library ourselves at this time.

[Sherlockzms]

Hi Signal Team 👋

Thank you so much for your reply！

First of all, I want to say that what you’ve built is really amazing — the integration between Rust and Swift through LibSignalClient is quite impressive, and your documentation is very helpful!

I’ve been trying to rebuild the Rust static library into an .xcframework, but unfortunately failed due to some incompatibilities.

Because of CocoaPods/CocoaPods#7606, it’s not really possible to mix .a static libraries and .framework dynamic libraries in the same project without use_frameworks!, which affects many existing projects that prefer to link .a libraries for performance reasons.

If the Signal team could help make a .a-compatible build of LibSignalClient (or signal_ffi) — perhaps a statically linkable target without requiring framework packaging — it would be a huge help and greatly appreciated!

Also, I’m curious — since CocoaPods is no longer actively maintained, are there any plans for the Signal team to explore more modern build systems like Bazel, or others for future integration?

Thanks again for your awesome work
Looking forward to your thoughts.