Binary distribution plans?

[buranmert]

hi everyone 👋

we are using Kronos as a dependency in Datadog iOS SDK and we were wondering if you had any plans for distributing Kronos as binary / xcframework?

[keith]

I'm definitely up for us doing this in general, if you have an example of the type of config you ship that kinda thing with that would be great (or if you want to PR it! 🙏🏻 )

[buranmert]

tl;dr: my PR above breaks Kronos for carthage users who mix Swift with Obj-C, i'm reverting it if that's ok with you.

hi again @keith 👋
i've just found out BUILD_LIBRARY_FOR_DISTRIBUTION is incompatible with Obj-C bridging headers.
if the client app has a bridging header / mixes Swift&ObjC then it cannot use a framework built with this build setting.
this WWDC session somehow mentions it (but leaves it unclear).
i'm raising a new one to revert it, sorry about raising the first PR too early!

it probably makes sense to let the user choose between downloading binary directly (build for distro) and building from the source (NOT built for distro).
SPM and Cocoapods don't have such a mechanism; carthage has no-use-binaries flag but AFAIK you can't choose which dependencies to use binaries and which not to, so this is not a viable option neither.
from what i understand, the effort for distributing binaries of an open-source project isn't worth the juice; it looks like it only makes sense for closed-source frameworks. after all, they can cache their dependencies in their ways after building from the source.

this topic turned out to be much more complex than i initially expected, please let me know if i'm missing something or if you have a different idea 👂

[keith]

yea it seems like this has always been a huge pain, which is why I love building our dependencies from source in a way that we define 🙃 . I think having a separate binary on each release would be fine with me though, and we could override that setting, if needed, in that build, separate from the CocoaPods or manual project integration routes.

[buranmert]

i thought it wasn't a pain anymore with xcframework and build_for_distro setting... but i turned out to be wrong :(

my initial idea was that if DatadogSDK and Kronos provide binaries then our regular users (who use SPM/cocoapods/carthage) can download both binaries easily with the help of package managers.
but due to that bridging header limitation, providing binaries via package managers is not really an option.

please let me do a bit more research while keeping the issue open ⏳ (but i will probably close the issue without further action)

we as Datadog still may need to provide binaries but this will be for non-package-manager-users and i think it makes more sense to provide a single standalone binary for them (only Datadog.xcframework which statically contains Kronos inside).

[keith]

statically linking Kronos in your xcframework is normally Lyft's preferred way to include 3rd party binaries as well

[buranmert]

hi again @keith 👋
i'm closing the issue. for now we decided to go with providing standalone binaries (a zip file containing OurFramework.xcframework and Kronos.xcframework in Github releases) for the users who don't use package managers.

i want to correct a mistake i made above:
Obj-C incompatibility issue was actually a mistake in my test project. when i set BUILD_LIBRARY_FOR_DISTRIBUTION = YES in the xcconfig for my framework target it was also affecting my app target (xcconfig was shared indirectly among both targets).
in short, BUILD_LIBRARY_FOR_DISTRIBUTION cannot be used in app targets but you can use it in framework targets without problem 👌
it still doesn't look like a good idea to distribute binaries via SPM and Cocoapods.