Static vs. Dynamic Linking: Code Size vs. Flexibility

Why it exists

Apps need to use shared code from libraries. The core problem is how to package and load that code. The choice between static and dynamic linking is a fundamental tradeoff between creating a self-contained package versus an efficient, flexible one that can be updated independently.

The mental model

Static linking is like baking a cake with all ingredients (libraries) mixed directly into the batter (the app executable). The final cake is huge but has everything it needs inside. Dynamic linking is like getting a recipe that lists ingredients you fetch from the system's pantry (the OS) only when you're ready to bake.

How it works

A static linker combines your compiled code with the library code into a single, large executable file. When your app launches, this entire file is loaded into memory. In contrast, dynamic linking doesn't copy the library code. It just records a reference. At launch, the operating system's dynamic loader (dyld) finds these libraries, loads them into memory, and connects your app to them. If another app uses the same library, the OS can share the single copy in memory.

When to use it

Use dynamic linking for most modern app development. All system frameworks like UIKit and SwiftUI are dynamic, which is how OS updates can improve your app's behavior without you recompiling. It reduces your app's download size and can improve launch time by loading code only when needed. Use static linking for small, simple dependencies where you want to lock to a specific version and avoid managing external files.

When not to use it

Avoid static linking for numerous or large libraries, as it dramatically bloats your app's binary size and initial memory footprint. It also complicates updates, as fixing a bug in a static library requires you to recompile and reship your entire app. For dynamic libraries, the footgun is versioning: if you create and distribute a dynamic library, you are responsible for maintaining API compatibility. A breaking change will crash client apps.

One canonical example

Every iOS app uses the UIKit framework. Your app's executable file does not contain the code for UIButton or UIViewController. Instead, it is dynamically linked against the UIKit framework provided by the operating system. When Apple updates iOS, they can fix bugs or improve performance in UIKit, and your app benefits automatically without you shipping a new version.