I've been updating a static library to support bitcode, and from my research I found two ways to achieve that:

Adding the fembed-bitcode flag to the Other C flags option in my project Build Settings (link)

Adding a User-defined Setting with the key BITCODE_GENERATION_MODE set to bitcode (link)

Is there any difference between these two options?

The only difference I noted is that by using fembed-bitcode, the resulting static library for iphonesimulator will be built with full bitcode enabled (in my case, binary size changes from 5MB to 13MB, and I can check bitcode support using otool), which doesn't seem to make any difference in its usage.

fembed-bitcode flag

Given that, if you add the -fembed-bitcode flag to the Other C flags, you will be sending two flags to the compiler during the compile time. It maybe silence some warnings that you can receive when using the library linked on another project. But, you need to check if you get the expected behavior. :)

(When I tested using the -fembed-bitcode on the Other C flags, Xcode gave the warning clang: warning: argument unused during compilation: '-fembed-bitcode-marker')

BITCODE_GENERATION_MODE

On the other hand,

If you set BITCODE_GENERATION_MODE=bitcode on your User-defined Setting, even during the build phase, the files will be compiled using the flag -fembed-bitcode.

And, if you set BITCODE_GENERATION_MODE=marker, the files will be compiled using the flag -fembed-bitcode-marker, independent of the action phase.

So, if you want to enable the bitcode to every action (build and archive), the better way to do so is using the BITCODE_GENERATION_MODE setting.

So, in the end, they really are just two different ways of achieving the same result, forcing Xcode to build with bitcode support without using the Archive action? Except that apparently fembed-bitcode will throw a warning along with it.
– heitortsergentJan 23 '16 at 15:33

3

Basically, yes. But, I recommend you to use BITCODE_GENERATION_MODE, if you really want to enable bit code to all actions. The duplicated flag may cause more than a warning.
– Igor Castañeda FerreiraJan 23 '16 at 15:42

Is it possible to remove the bitcode after compilation? For instance in a case where a framework has bitcode but the consumer doesn't compile with bitcode enabled support? In that case the bitcode would need to be removed before the consumer would be able to succesfully compile. In a case where the framework wasn't compiled with bitcode and the consumer would have bitcode enabled they wouldn't be able to compile their project as well. So basically the question is how to strip bitcode from the binary :)
– Avner BarrAug 3 '16 at 11:56

@AvnerBarr the "over information" was is easy! You don't need to strip the bit code. If you build a framework with bit code enabled and the client app have bit code disabled, the final product will not be affected by the extra content on the framework. The other way around is impossible. The framework need to have bit code to the used in a project with bit code enabled. An example of the bit code behaviour can be seen on this project: github.com/igorcferreira/BitcodeLibrary
– Igor Castañeda FerreiraAug 4 '16 at 13:59