Shall the Xcode plane land?
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
Xcode's power comes at the cost of relying heavily on implicit behavior and side effects, a form of technical debt that grows painful as projects scale—manifesting as unpredictable build failures, broken Swift Previews, and confusion over static/dynamic linking and framework/library choices. The overlap between Xcode's native project model and Swift Package Manager compounds this, since Apple must reconcile two separate, partly implicit graph languages. A vision is proposed for how Apple could fix this: a single unified, side-effect-free graph language for both local and remote modules, a hermetic and cacheable build system, treating implicitness as an invalid state that fails fast, automatic static/dynamic decisions, truly atomic output products, and better documentation—changes that would ideally make third-party project generation tools like Tuist unnecessary.
Table of contents
ScalingConvenience through implicitnessSharing codeMy Swift previews stopped workingSPM as a project managerWhat if the plane could be landed?Closing wordsQuestions this post answers
Why do Swift Previews randomly stop working in large Xcode projects?
Swift Previews tend to break more often as a project's module graph grows larger and more implicitly linked, because Xcode's editor struggles to determine what needs recompiling when dependencies aren't explicit. Previews work more reliably with dynamic frameworks, which are self-contained, compared to static libraries that require extra exposure of Swift modules or headers. Developers debugging flaky Swift Previews can follow build-system deep dives like this on daily.dev.
What's the difference between how Xcode projects and Swift Package Manager define module graphs?
Xcode projects define a module graph implicitly and are resolved synchronously as part of the project file, while Swift Package Manager defines dependencies explicitly in Swift but resolves the graph asynchronously and reports back to Xcode's UI. This mismatch causes package resolution failures, invalid states, and regressions because Apple must reconcile two different build processes. Teams weighing Xcode project files against SPM for module management can track these tradeoffs on daily.dev.
Should an Xcode framework be static or dynamic to avoid build issues?
There's no universal rule, but implicit static/dynamic decisions are a major source of Xcode build errors, bloated binaries, and inconsistent Swift Previews behavior. Tuist recommends making dependency types explicit rather than relying on Xcode's implicit resolution, since Apple already has enough information (module graph, platform, build configuration) to make this decision deterministically but currently doesn't. Anyone untangling static versus dynamic linking choices in Xcode can find this kind of analysis on daily.dev.