How to reduce the size of iOS executable files

Reducing the size of iOS installation packages is something that many medium and large APPs have to do. Generally, they will start with resource files, compress images/audio, and remove unnecessary resources. After these resource optimizations are completed, we can also try to slim down the executable files. The larger the project, the larger the volume occupied by the executable file. Because the AppStore will encrypt the executable file, the compression rate of the executable file is low. After compression, the executable file accounts for about 80%~90% of the volume of the entire APP installation package, which is still worth optimizing. The following introduces the points that can be optimized in the process of studying executable files. Linkmap was used in the research process. For the introduction and generation of linkmap, please refer to another article—The composition of iOS executable files.
Compile options

1. Compiler optimization level

Build Settings->Optimization Level has several compilation optimization options. The release version should select Fastest, Smallest. This option will enable all optimizations that do not increase the code size and make the executable file as small as possible.

2. Remove symbol information

Strip Debug Symbols During Copy and Symbols Hidden by Default should be set to yes in the release version to remove unnecessary debugging symbols. Symbols Hidden by Default will define all symbols as "private extern". I am not sure about the specific meaning and function, and it needs to be studied, but it will reduce the size after setting it. These options are currently XCode default options, but projects generated by old versions of XCode may not be, you can check it.

For other optimizations, please refer to Apple’s official document—CodeFootprint.pdf
Third-party library statistics

Many third-party static libraries are introduced into the project. If we know the size of these third-party libraries in the executable file, we can evaluate whether it is worthwhile to find an alternative to remove this third-party library. We can count this information from the linkmap. I wrote a node.js script that can count the size of each .o target file and each .a static library through the linkmap, and sort them. See here for details (need to climb over the firewall).
ARC->MRC

Some people have suggested that the executable file compiled by the code written in ARC will be larger than that compiled by MRC. The reason is that ARC code will have more retain and release instructions in some cases. For example, when a method is called, the object it returns will be retained and released after exiting the scope, but MRC does not need it. The more assembly instructions and machine codes, the larger the executable file. There are other differences in implementation details, but I will not dwell on them for now.

How much will the size increase when using ARC? I think it is difficult to calculate accurately by increasing or decreasing the number of assembly instructions. This involves too many details, so it is better to calculate from a statistical perspective. I did several comparative experiments and counted the size of the __TEXT code segment of several open source projects that support both ARC and MRC with ARC turned on or off. I only compared the __TEXT code segment because:

ARC's impact on executable file size is almost entirely in the code segment.

Executable files will be aligned in some way. For example, some segments will be filled with 0s when they are less than 32K until they are aligned to 32K. If you compare the executable file size, the result may be after alignment and is inaccurate.

Experimental data:

The result is that ARC will probably increase the size of the code segment by 10%. Considering that the code segment accounts for about 80% of the executable file, the estimated impact on the entire executable file will be 8%.

You can evaluate whether an 8% size reduction is worth converting some modules in the project to MRC. This will increase the maintenance cost of the program. It is generally not recommended to do so unless there are special circumstances.
Useless code

Create a new class in the project and add a few methods to it, but don't import it anywhere. After building the project and observing the linkmap, you will find that this class is still compiled into the executable file.

According to C++ experience, the compiler will optimize unused classes and methods and will not compile them into the final executable file. However, object-c is different because it can obtain the class and method through reflection of the class and method name for calling. Therefore, even if a class is not used in the code, the compiler cannot guarantee that the class will not be called through reflection at runtime. Therefore, as long as it is a file in the project, it will be compiled into the executable file regardless of whether it is used.

We can use a script to traverse the files of the entire project, find all the unreferenced class files and uncalled methods, and remove them without dynamically calling them elsewhere. If the entire project takes a long time and there are many legacy codes, this cleanup can save considerable space for the executable file.
Class/method name length

By observing the linkmap, we can find that each class and method name has a corresponding string value stored in the __cstring segment, so the length of the class and method names also affects the size of the executable file. The reason is still the dynamic characteristics of object-c. Because it is necessary to find the class/method through class/method name reflection for calling, the object-c object model will save the class name and method name list.

You can consider obfuscating all class and method names before compiling, and replacing long names with short names. In addition to reducing the size, this also greatly improves security. When someone gets the executable file and class-dumps it, the results are all obfuscated class and method names. It is impossible to guess what a method does from the class and method names, and it is difficult to hook and hack. However, there is a disadvantage that the method name of the stack decompressed from the crash stack will be obfuscated, and another layer of obfuscation -> original name conversion is required, which is a bit costly to implement and use.

In fact, this part occupies a relatively small length, and a medium-sized project only takes a few hundred KB. You can try it if you have high security requirements.
Redundant Strings

All static strings defined in the code will be recorded in the __cstring segment of the executable file. If there are a lot of logs in the project, the space occupied by this file is also considerable, and it is also several hundred KB in size. You can consider cleaning up all redundant strings. In addition, if there are particularly long strings, it is recommended to extract them and save them as static files, because AppStore encrypts executable files, resulting in a low compression rate. The compression rate of particularly long strings extracted into static resource files will be much higher than that in executable files.
CheckList

Finally, I will simply list various methods to reduce the size of iOS installation packages as a checklist:

Link to this article: http://www.cocoachina.com/ios/20150202/11084.html