Controlling __TEXT Segment Size in iOS Apps: Practices, Tools, and Metrics
The article explains how iOS engineers keep the __TEXT segment under Apple’s strict size limits by removing unused code, using Link Map analysis, applying a custom SizeLine metric, and adopting coding practices such as limiting blocks, macros, and hard‑coded strings, all supported by automated monitoring and feedback.
Author Apan, a senior iOS engineer at iQIYI, shares practical experience on keeping the __TEXT segment of iOS app binaries under the strict size limits imposed by Apple (e.g., each architecture must be less than 60 MB for iOS 8.0+ support).
The article first outlines the motivation: large apps continuously grow in size, making it essential to monitor and reduce the __TEXT segment.
1. Removing Unused Code
• Delete unused classes – encourage reusable components and avoid copying code.
• Delete unused selectors – although Objective‑C’s dynamic runtime makes it hard to find unused selectors, the author describes a method that parses the Link Map file and the __DATA.__objc_selrefs segment using otool to identify methods not referenced in the binary. The author advises against this approach due to high false‑positive rates.
• Use the open‑source tool fui to locate dead Objective‑C classes, while warning that manual verification is required because of possible runtime‑generated selectors.
2. Monitoring Segment Size
The team relies on Link Map files generated by Xcode (enable with Write Link Map File = YES in Build Settings). The Link Map provides a complete view of every .o file and its contribution to the __TEXT segment.
Key monitoring steps include:
Analyzing each module’s total __TEXT size and assigning owners to keep it within limits.
Sorting .o files by size to identify large contributors.
Grouping by Xcode project groups for finer‑grained statistics.
Tracking per‑file size changes across daily builds using Jenkins jobs that automatically parse Link Maps.
These analyses are visualized with screenshots (omitted here) and referenced blog posts such as https://blog.cnbang.net/tech/2296/ .
3. SizeLine (SL) Metric
The team defined a custom metric called SizeLine (SL), calculated as file size (bytes) / number of source lines . A high SL often indicates files with many autogenerated accessor methods (e.g., data models) or heavy use of macros. An SL below 60 is considered acceptable; higher values trigger further investigation.
4. Writing Smaller Code
Practical tips include:
Minimize the use of blocks – blocks are objects that increase __TEXT size.
Be cautious with macro definitions – avoid multi‑line macros and excessive statements.
Prefer resource files (e.g., plist) over large hard‑coded string arrays, as repeated string literals inflate the __TEXT segment.
Case studies demonstrate measurable reductions, such as removing a Masonry‑based layout block from QPChatCellViewCrowdFunding.m , which saved ~9.1 KB in the binary.
Conclusion
Controlling the __TEXT segment requires a combination of clean code practices, automated monitoring, and continuous feedback loops throughout the development lifecycle. By integrating these strategies, engineers can balance feature growth with binary size constraints.
iQIYI Technical Product Team
The technical product team of iQIYI
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.