Provide static binaries?

[keith]

Is there any chance that you all could provide static framework versions of Instabug as well as or in place of the dynamic ones? CocoaPods supports this for the past few versions. There are 2 benefits I think we'd see.

1. Any unused symbols could be removed at link time. Meaning if consumers of the SDK don't end up using the whole thing, they can end up with a smaller binary size increase from integrating Instabug.

2. This decreases the amount of dynamic linking time when the apps are being launched, which helps the app launch faster.

Thoughts?

[Kmohamed]

@keith Make sense let me check it and get back to you.
Thanks a lot 🙏

[HeshamMegid]

CocoaPods supports this for the past few versions.

@keith as far as I understand, the newly introduced s.static_framework = true is only relevant for source pods. Since we distribute a binary, we would have to maintain 2 separate podspecs and 2 different sets of binaries if we want to give the pod consumer the liberty of choosing whether to integrate as a static or dynamic framework.

We’re looking into whether we should maintain versions of both static and dynamic, and if dropping the dynamic framework wouldn’t work for certain use cases. We’ll get back to you soon.

Also, out of the 2 benefits you mentioned, which one is more important? I'm asking since the first one could be achieved by breaking our framework into smaller subspecs.

[keith]

@keith as far as I understand, the newly introduced s.static_framework = true is only relevant for source pods.

Ah right I'm sorry, this is actually irrelevant because CocoaPods has supported this for a while. The GoogleMaps pods for example are pre-compiled static frameworks.

Since we distribute a binary, we would have to maintain 2 separate podspecs and 2 different sets of binaries if we want to give the pod consumer the liberty of choosing whether to integrate as a static or dynamic framework.

While you would have to have 2 sets of binaries if you wanted to support both, you could maintain a single pod spec using subspecs, which would simplify things a bit.

if dropping the dynamic framework wouldn’t work for certain use cases

Unless anyone is doing something crazy, there shouldn't be a difference to consumers. The only thing you might have to change is your resource loading

Also, out of the 2 benefits you mentioned, which one is more important? I'm asking since the first one could be achieved by breaking our framework into smaller subspecs.

We're interested in this for some more reasons that just those I mentioned. Currently Instabug is our only dependency that isn't static, so we're trying to unify that to simplify our build tooling.

[kastiglione]

if dropping the dynamic framework wouldn’t work for certain use cases

A dynamic framework (MH_DYLIB) can always be produced out of a static library/framework, but of course the reverse is not true. It's possible to ship one binary, a static one, and then add a step that transforms the static binary into a dynamic framework, for those that need it. Happy to help figure this out, if there's interest.

[HeshamMegid]

A dynamic framework (MH_DYLIB) can always be produced out of a static library/framework, but of course the reverse is not true.

We were not aware of that. That will definitely make things easier.

Thanks @keith and @kastiglione! We will continue discussing this internally and get back to you soon.

[keith]

Another benefit I just realized to providing a precompiled static framework, is you could remove this script referenced in your readme since this would be handled automatically by the linking process.

[HeshamMegid]

We’ve decided to switch to a static framework. We’ll be working on it this week, so it should be available in either the next release or the one after. Will let you know once it’s released.

@kastiglione I couldn’t find much that talks about transforming a static binary into a dynamic one. If you have any resources that talk about this, I’d really appreciate if you share them.

[keith]

Awesome! Thanks!

…

-- Keith Smiley

On May 20, 2018, at 04:07, Hesham Abd-Elmegid ***@***.***> wrote: We’ve decided to switch to a static framework. We’ll be working on it this week, so it should be available in either the next release or the one after. Will let you know once it’s released. @kastiglione I couldn’t find much that talks about transforming a static binary into a dynamic one. If you have any resources that talk about this, I’d really appreciate if you share them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[kastiglione]

@HeshamMegid I don't know if there are resources that talk about it. Here's an overview.

The two main kinds of binary files in this discussion are:

1. Intermediate build files (object files, static libraries)
2. Product binaries (executables, dynamic frameworks, dynamic libraries)

Source files are compiled into intermediate build files, and those intermediates are in turn linked into binaries that can be loaded and run.

Dynamic frameworks (and executables) can be produced from any combination of .o object files and static libraries. From an Xcode perspective, you could imagine three targets:

1. Application
2. Static library
3. Framework

These three targets could be structured with the majority of the source files as part of the static library. The application and framework would in turn link in the static library via Xcode's "Linked Frameworks and Libraries" section. In this example, Xcode would build a static library, and then use that to produce the app and the framework.

To do all this linking, Xcode isn't doing anything fancy, it calls commands in the toolchain. At its most basic, converting a static library to a framework would look like this:

mkdir -p path/to/X.framework
ld -dylib path/to/libX.a -o path/to/X.framework/X

Typically build systems don't use ld directly, they use clang or swift to invoke the linker. Xcode for example does something like this:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-arch x86_64 \
-dynamiclib \
-isysroot path/to/iPhoneSimulator11.3.sdk \
-Lpath/to/deriveddata/Build/Products/Debug-iphonesimulator \
-Fpath/to/deriveddata/Build/Products/Debug-iphonesimulator \
-lStaticTargetName \
-o path/to/TargetName.framework/TargetName

I've reduced this a bunch to focus on what would be relevant for the discussion. The flags above are the most noteworthy (but not necessarily required). Despite the use of clang, no source code is bing compiled, instead the clang command is a "driver" that in turn runs ld. The point being that you can use clang or you can use ld, whatever suits the needs best. To see the underlying ld command line, you can add a -### flag to the clang command.

Hopefully this helps some, I'm happy to answer more questions. To support both static and dynamic, you probably have two primary options: 1. Use the Xcode structure I mentioned above: a static library target and a framework target, where the framework has no code and simply links in the entirety of the static library, or alternatively 2. Release binaries that contain just static frameworks, but also provide scripts that generate a dynamic framework on the developer's machine.

[HeshamMegid]

@kastiglione thank you so much for taking the time to write this up! We'll give it a try as soon as we change our build scripts to produce a static framework.

[Kmohamed]

@keith I face some problems with cocoapods and static library I hope that you can help me to fix it
I wanna using development pods inside static library target but for some reason the static target can not find the development pods. I tried to remove use_frameworks but it did not work.
any suggestions ?