Static library versus dynamic framework linking

WHAT THIS TESTS The interviewer is checking whether you understand the linking phase and can reason about the concrete cost of each choice on disk size and cold launch, a topic that matters at scale with many modules.

A GOOD ANSWER COVERS A static library, such as a .a archive or a statically linked Swift package, is resolved by the linker at build time: the referenced object code is copied directly into the app's main executable. There is no separate file to load at launch, so startup pays no extra dynamic-linking cost, but the executable grows and the same code linked into multiple binaries is duplicated. A dynamic framework is a standalone Mach-O loaded at launch by dyld, which maps it, resolves symbols, and runs any initializers. Dynamic linking lets multiple consumers share one copy and keeps the main executable smaller, but every framework adds dyld work, so an app with very many dynamic frameworks suffers measurably slower cold launches.

COMMON WRONG ANSWERS Claiming dynamic frameworks always make the app smaller; on iOS, app-bundled dynamic frameworks still ship inside the app and add load cost. Saying static linking always slows launch, which reverses the reality. Ignoring that excessive dynamic frameworks were a known launch-time problem Apple advised limiting.

LIKELY FOLLOW-UPS What is dyld and what does it do at launch? Why might you merge many small dynamic frameworks into fewer? How does this interact with Swift's runtime and mergeable libraries?

ONE CONCRETE EXAMPLE An app with forty tiny dynamic frameworks shows a noticeably slower cold launch because dyld must load and link each at startup. Converting the rarely-shared ones to static linking removes that per-launch cost, trading a slightly larger executable for faster startup. Conversely, a framework genuinely shared by an app and its extension benefits from dynamic linking so the code exists once rather than duplicated into each target.