---
title: "Shall the Xcode plane land?"
url: https://daily.dev/posts/shall-the-xcode-plane-land--n9gdryi0c
source_url: https://tuist.dev/blog/2024/09/20/xcode-plane
type: article
source: "\n      Tuist\n    "
published: 2026-08-23T12:23:51.051Z
updated: 2026-08-23T12:55:59.681Z
tags: ["ios", "swift", "xcode", "build-systems"]
reading_time: 15
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Shall the Xcode plane land?

**[
      Tuist
    ](https://daily.dev/sources/tuist-blog)** · 15 min read · 0 upvotes · 0 comments

## Summary

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.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://tuist.dev/blog/2024/09/20/xcode-plane>

## Questions 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._

---

Tags: [#ios](https://daily.dev/tags/ios), [#swift](https://daily.dev/tags/swift), [#xcode](https://daily.dev/tags/xcode), [#build-systems](https://daily.dev/tags/build-systems)

[View this post on daily.dev](https://daily.dev/posts/shall-the-xcode-plane-land--n9gdryi0c)