On the exploration of Bitcode

Bitcode Overview Bitcode is an intermediate representation of a compiled program. Apps you upload to ITunes Connect that contain bitcode'll be compiled and linked on the store. Including Bitcode'll allow Apple to re-optimize your app binary on the future without the need to submit a new version O F your app to the store. Xcode hides symbols generated during build time by default, so they is not readable by Apple. Choose to include symbols when uploading your apps to iTunes Connect would the symbols is sent to Apple. You must include symbols-to-receive crash reports from Apple.

The above is quoted from Apple's document APP thinning (IOS, TvOS, WatchOS).

It probably means that Bitcode is similar to an intermediate code, and after being uploaded to Applestore, Apple will generate only the binary of that instruction set based on the user's mobile instruction set type of the app being downloaded. The purpose of streamlining the package volume is achieved.

Bitcode is the encoding of the LLVM compiler intermediate code. The front-end of LLVM can understand programming languages, which are used to write applications. The backend LLVM can understand how to show the executable version of the app that the user is downloading. Bitcode is somewhere between these two steps. LLVM transforms an app's source code into Bitcode, and then transforms the Bitvode into an executable application. This design allows it to easily add support for new languages (front end) as well as new CPUs (backend). Although Bitcode cannot run on any platform, it can be translated into any supported CPU architecture, including those not yet available before the app is submitted to the store.

A little bit of compiling principle

To better understand what Bitcode is, let's take a short look at the compiler compile process:

• Lexer: Read into the source file and convert it into a character stream
• Parser: Converting character flow to AST (abstract syntax tree
• Semantic Analysis: syntax checking of the input AST.
• Code Generation: Generating the AST into a low-level IR directive
• Optimization: Analyze the IR instruction to kill the instruction which will potentially slow down the running speed.
• Asmprinter: Generate assembly code for specific CPU architectures via IR (intermediate code)
• Assemble: Converting assembly code into binary

• Linker: Usually the program references other binaries (. A or framework), but these links do not have the correct address in the program, just a placeholder. Linker's job is to give these placeholders the correct address.

In general, in the real compiler framework, the above process will be divided into the front and back end of the two parts to deal with:

The IR (median) is passed between the front and back ends, and Bitcode is a special form of intermediate code. The previous work was done in the local LLVM, although Apple did not give a specific bitcode implementation, but through their documentation, it was possible to move a portion of the backend work to the server. Upload the IR to the server from Xcode, and the server will do the following for the different models. In order to achieve a true pair of different models generated corresponding instruction set of binary, and reduce tabloid volume purposes.

Open Bitcode Settings

In fact, in Xcode 7, when we create a new iOS program, the Bitcode option is set to Yes by default. We can see this setting in the "Build Settings", "Enable bitcode" option.

However, what we need to consider now is three platforms: Ios/mac Os/watchos.

• The corresponding Ios,bitcode is optional.

• is necessary for Watchos,bitcode.

• MAC OS does not support Bitcode.

If we open the Bitcode, the following interface will also have a bitcode option when submitting the package:

However, if it contains a third-party library, Bitcode is not supported. You need to set "Enable Bitcode" to No. And this option is, as long as there is a third-party library is not supported, can not open. Otherwise, the connection error.

Be sure to use Fembed-bitcode instead of fembed-bitcode-maker when packaging

You should is aware that a normal build with the-fembed-bitcode-marker option would produce minimal size embedded Bitcode Sections without any real content. This was done as a a-testing the bitcode-related aspects of your build without slowing down the build process. The actual Bitcode content is included when you do an Archive build.

• Fembed-bitcode-maker: Simply mark the location of Bitcdoe in the binary archive.

• Fembed-bitcode: It really generates BITCODE instructions and is embedded in the binary, which is not only set in the app, but you also have to use it when compiling a static link library. And the theme is that this parameter system will only be added by default in archive mode.

It is important to note that Bitcode is compiled only by default under archive. Not at debug or release.

If you are developing an app then go for a normal package archive process. If you are developing a static library or framework, be aware that the package is set to archive, or include the-fembed-bitcode parameter in the packaging script. If necessary, you need to open Deployment_postprocessing=yes in build settings, set strip style to debugging.

Detect if Bitcode is turned on

When the Bitcdoe option is turned on, we can use the Otool tool to check whether a Bitcode segment is included in a binary file.

for static link libraries. A file

Otool-arch Armv7-l xxxx.a | grep __bitcode | Wc-l

If the current library supports. A file will output a number

This number does not appear if Bitcode is not supported.

The above command only examines the ARMV7 schema, and you must also use the change command to check if the other instruction set contains bitcode such as: arm64,armv7s, etc.

Check whether the app or the framework contains Bitcode

Because the binary and framework binaries in the app differ from the. A file, because the __LLVM segment needs to be checked, it is supported when the segment is present, or bitcdoe is not supported.

otool-l xxxx | grep __LLVM | Wc-l

There is a bug in this otool that when your framework uses the Lipo command to disassemble and merge, you need to specify the instruction set for checking.

Otool-arch armv7-l xxxx | grep __LLVM | Wc-l

But, after the above inspection, it is not necessarily true support Bitcode, in the actual test, found that the above detection command passed, a third-party library used, still error does not support Bitcode. Thus, the end result is still the need to be able to connect success to prevail. Important things say three times, the above online circulating detection method only for reference, and ultimately to the actual effect of the prevail.

Final result Check

If you are an app, you can directly archive packaging, if it is a library, it is recommended to build a demo project to package, remember to open the Bitcode settings.

CheckPoint1 Connection is Error

If any of the libraries do not have a bitcode link open, an error similar to the one below will appear.  As long as the chain has been, then congratulations, basically OK. The above article excerpt from: http://www.cocoachina.com/ios/20151201/14432.html thanks

On the exploration of Bitcode