Static library versus dynamic framework linking
linking models and their runtime cost.
static code is copied into the executable at build time; dynamic is loaded at launch by dyld. Trade-off: static bloats the binary but avoids load cost; many dynamic frameworks slow launch.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
An app links forty small dynamic frameworks and has slow cold launch. Why might converting some to static linking help?
- a.Dynamic frameworks cannot be used on physical devices
- b.It removes per-launch dyld load and symbol resolution work for those modulesCorrect
- c.Static linking compresses the binary so it downloads faster
- d.Static code runs at a higher CPU priority
Why? this is the answer
Each dynamic framework adds dyld loading and linking work at every launch, so statically linking them moves that resolution to build time and speeds startup. It does not change download compression, CPU priority, or device compatibility.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
- #ios
- #linking
- #static-library
- #dynamic-framework
- #performance
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles