Analyze iOS App Binary size with Link Map

Why?

As an iOS developer, it is often a concern that the size of the app will be a factor in whether or not a user decides to download the app when they see it in the App Store, and if the app is too large, it may discourage users from downloading the app, especially if they are on a cellular network.

For an iOS App, its size usually consists of the following components:

• Executable binary files
• Resource files
• Third Party Framework

For resource files and third-party frameworks, we can count the disk space they occupy by counting the file size directly, but for binary files, how do we count the size of the code it contains?

How?

Luckily, Xcode provides us with a statistics file like Link Map to show the actual size of the code in the executable binary after compilation, and by analyzing this file, we can know exactly how much of the final executable binary it will occupy for each code file.

In order for Xcode to generate the Link Map file we need, we need to go to the project’s settings screen in Xcode, select the target which we need to generate the Link Map, select the Build Settings tab, enter “link map” in the search box (attention that there is a space between link and map), and then you will see the following settings.

Change Write Link Map File to Yes, and change Path to Link Map File to a path that is easier to find, for example here I changed it to test-linkmap.txt in my Download directory.

The contents of a typical Link Map file are shown below:

Where # identifies the contents of each block, the Link Map contains the following blocks.

• Path: The executable binary corresponding to the Link Map file
• Arch: The CPU architecture of the compiled executable binary
• Object files: list of object files generated by each source file after compilation
• Sections: list of sections where different types of code are located in the final executable binary
• Symbols: The actual list of all functions, variables, strings, etc. generated in the code

How to statistics?

We don’t need to care about the contents of Sections, because it just corresponds to the location of the different symbols stored and doesn’t affect the actual data size it takes up. We need to pay attention to the Object files and Symbols, because they actually contain the part of the executable binary that occupies the volume.

For example, in the above example [ 1] /Users/ohdarling/Library/Developer/Xcode/DerivedData/LinkMapAnalyzer-atehkijmusbhcoahevnvjewudpxp/Build/Intermediates.noindex/LinkMapAnalyzer.build/Debug/FLMAApp.build/Objects-normal/x86_64/LMWindowController.o：

• [ 1] indicates that this object file has the index number 1
• /Users/ohdarling/Library/...... /LMWindowController.o indicates the path to this object file
• LMWindowController.o usually indicates that the object file is generated by LMWindowController.m

Then again in Symbols, we can analyze the data size occupied by each function, variable, etc. in each code file and the object file where it is located, e.g. 0x100002CC0 0x00000080 [ 1] - [LMWindowController windowDidLoad]:

• 0x100002CC0 indicates the address of this function in the executable binary file
• 0x00000080 means that the size of the instruction code generated by this function is 128 bytes
• [ 1] means the function is in the object file numbered 1
• -[LMWindowController windowDidLoad] means that the signature of this function is the windowDidLoad method in LMWindowController

In the symbol list, we can get the size of each function of each class, and then correlate it by object file number, we can count the size of the volume of the instructions generated by each code file in the final executable binary file.

Generate Analyze Result

By analyzing Object files and Symbols, associating them with object file numbers, and mapping object files to file system filenames, we can finally obtain the size of each object file, and each function in the entire executable binary file.

After getting the analysis results, we can clearly know if there are modules in the whole project that are too large, and if this problem exists, then we need to invest time to try to troubleshoot for redundant code, or deprecated code, so as to reduce the size of the final executable binary and give the user a better download experience.

Conclusion

By analyzing the Link Map file, we can accurately calculate the volume of each function, variable, etc. in the executable binary file, so that we can target the iOS App size optimization.

In order to analyze the Link Map results more quickly and intuitively, I wrote a FastLinkMapAnalyzer app for macOS that generates tree diagrams and Treemap charts, so that you can visually see the largest modules in the whole app by means of charts.

Get FastLinkMapAnalyzer on Mac App Store: https://apps.apple.com/app/fastlinkmapanalyzer/id1595283055?mt=12

I hope this article is useful to you :)