Optimizing iOS App Startup and Download Size via Dynamic Library Migration and Lazy Loading

The article describes how a ten‑year‑old iOS application, composed of about 20 million instructions and over 60 000 classes, was refactored to improve launch performance and reduce download size by migrating many static SDKs to dynamic frameworks and applying lazy loading.

Background: Numerous third‑party SDKs are loaded at startup, many of which are rarely used, causing wasted initialization time. Conventional compression techniques had exhausted their gains, prompting a shift to incremental updates via dynamic libraries as suggested by Apple.

Industry Survey: While new iOS apps often adopt dynamic frameworks, large legacy apps are cautious, and lazy‑loaded dynamic libraries are rarely used.

Solution Process: The team decided on a bottom‑up approach, first converting stable, low‑change SDKs into dynamic libraries. Thirteen SDKs were turned into dynamic frameworks, with ten of them configured for lazy loading.

Identifying SDK Dependencies: Dependency relationships were extracted by parsing the symbol tables of static libraries. The struct nlist_64 { union { uint32_t n_strx; } n_un; uint8_t n_type; uint8_t n_sect; uint16_t n_desc; uint64_t n_value; }; definition and related N_TYPE constants (e.g., #define N_UNDF 0x0 ) were used to separate external (undefined) and internal symbols, allowing the construction of dependency graphs.

Dynamic Library Dependency Configuration: When SDK A depends on SDK B, both must be built as dynamic libraries and linked together. CocoaPods 1.8’s use_frameworks feature was employed to manage N+K pod relationships, ensuring consistent versions across libraries.

Reducing Business Code Changes: Header files were kept unchanged; static libraries were stripped of resources before being packaged as frameworks. Linker flags such as -all_load were replaced with -ObjC to avoid symbol conflicts, and unwanted object files were removed using ar -x and libtool -static -o .

Development Target & Bundle ID: The dynamic library’s deployment target must not exceed the host app’s iOS version, and each framework must have a unique bundle identifier to avoid installation failures.

Lazy Loading Configuration: Lazy‑loaded frameworks are excluded from the link phase and loaded at runtime via dlopen([path UTF8String], RTLD_LAZY) . Runtime checks ensure that a class is loaded only when first used, reducing startup overhead.

Lazy Loading Calls: Runtime class acquisition replaces static linking, e.g., DylibRedefineClass(IFlySpeechRecognizer) iflySpeechRecognizer = nil; iflySpeechRecognizer = [DylibObtainClass(IFlySpeechRecognizer) sharedInstance]; . Visibility attributes ( __attribute__((visibility("hidden"))) ) are used to hide symbols when necessary.

Quantifying Benefits: The migration reduced full‑package download from 88 MB to 74 MB for incremental updates and cut launch time by roughly 12 % (≈817 ms on iPhone 6 Plus iOS 12). Tables in the original article show pre‑main and static runtime initialization times for static vs. dynamic vs. lazy‑loaded libraries.

Conclusion: Bottom‑up dynamic library conversion with selective lazy loading yields measurable startup improvements and potential download savings, though it introduces additional maintenance complexity and requires careful dependency management.