16.3 · Static and dynamic linking, duplicate symbols, and the dependency graph
How modules are linked decides launch time, binary size and a class of bugs that appear only at link or run time. The shape of the graph decides what can build in parallel.
Mental model. Static copies code into the app at link time; dynamic loads a separate image at launch. The dependency graph must be a directed acyclic graph, and its shape is your build speed.
Link types
Static versus dynamic, and duplicate symbols.
- How do static and dynamic linking differ for an app, what do they cost at launch and in size, and what are duplicate symbols?
Static linking copies the needed code from a library (.a, or a static framework) into the final executable at build time. There is nothing to load at launch…
The graph
Cycles, layering and depth.
- Why must the module dependency graph be acyclic, how do you layer it, and what does its shape do to build times?
A module must be compiled after everything it imports, so dependencies must form a directed acyclic graph. If A depends on B and B on A, neither can be built…
More in Modularization & SPM
- 16.1 · Targets, products, modules, and access across module boundaries
- 16.2 · SPM, CocoaPods, Carthage and XCFrameworks, and shipping binaries
- 16.4 · Build settings, configurations, xcconfig, and compile times
- 16.5 · Resource bundles, localisation in modules, and feature flags
- 16.6 · Multi-hour CI, affected-module builds, caching, and Tuist and Bazel
- 16.7 · Version rules, pins, conflicts, unsafe flags, mirrors and inspecting the graph
- 16.8 · Conditional settings, platform minimums, language modes, traits and plugins
- 16.9 · What really crosses a module boundary: inlinable bodies and imports