为何需要Derived Data？探究Xcode独立存储派生数据的设计初衷

Great question—this is one of those Xcode behaviors that feels like a random hassle until you unpack the intentional design choices behind it. Let’s break down the core reasons, plus dive into how the caching mechanism actually speeds up builds:

Key Design Rationales #

• Separate source-controlled files from disposable build artifacts
  Your project directory should only hold files you care about long-term: source code, storyboards, project settings, and assets that need version control. Derived Data stores intermediate build files (like .o object files), compiled modules, and final products that can be completely regenerated from your source. This keeps your project folder clean, eliminates accidental commits of build junk (even with .gitignore, separating at the filesystem level is a stronger guard), and makes sharing or archiving your project way easier without bloating it with gigabytes of build outputs.

• Support parallel builds for multiple versions/configurations
  If you ever switch between Xcode versions (e.g., Xcode 14 and 15 for compatibility testing), or build different configurations (Debug/Release/Ad Hoc) or targets (iOS/macOS/watchOS) for the same project, Derived Data creates isolated subdirectories for each scenario. This prevents conflicts between build artifacts from different environments—something that would get messy fast if you tried to cram everything into your project folder (you’d end up with nested subfolders like Build/Debug-iOS, Build/Release-macOS, etc., which Xcode manages automatically in Derived Data).

• Avoid file access conflicts and permission issues
  Build processes often create temporary files, lock resources, or generate large frameworks. Keeping these in a dedicated Derived Data directory lets Xcode have full control over file operations, reducing conflicts with your code editor, Git client, or other tools that might be accessing files in your project directory.

How Derived Data Accelerates Builds (The Reference Mechanism) #

The speed boost comes down to smart caching and dependency tracking:

• Incremental build tracking: Xcode calculates a unique hash for every source file and its dependencies (compiler flags, linked libraries, header files). When you build, it only recompiles files where the hash has changed (i.e., the file itself or its dependencies were modified). The cached artifacts in Derived Data are referenced directly instead of rebuilding from scratch.
• Shared module caching: Swift and Objective-C modules (including system frameworks like UIKit or third-party libraries) are cached in a shared subdirectory of Derived Data. If multiple projects use the same module, Xcode reuses the cached version instead of recompiling it every time—this is a huge time-saver for common frameworks.
• Optimized product lookup: The Build/Products subfolder in Derived Data is where final binaries (.app, .framework) live. Xcode uses this standardized location to quickly locate products for testing, archiving, or deploying, avoiding the need to scan your project directory for build outputs.

While you can customize the Derived Data path or ignore it in Git (as you noted), the default setup is optimized to handle all these edge cases automatically, keeping your build process stable and efficient.

内容的提问来源于stack exchange，提问作者Chris G.