If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/fastred/Optimizing-Swift-Build-Times shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 7y ago

• 7 active contributors
• MIT licensed
• Tests present
• ⚠ Stale — last commit 7y ago
• ⚠ Concentrated ownership — top contributor handles 78% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live fastred/Optimizing-Swift-Build-Times repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/fastred/Optimizing-Swift-Build-Times.

What it runs against: a local clone of fastred/Optimizing-Swift-Build-Times — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in fastred/Optimizing-Swift-Build-Times | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2685 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of fastred/Optimizing-Swift-Build-Times. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/fastred/Optimizing-Swift-Build-Times.git
#   cd Optimizing-Swift-Build-Times
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of fastred/Optimizing-Swift-Build-Times and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "fastred/Optimizing-Swift-Build-Times(\\.git)?\\b" \\
  && ok "origin remote is fastred/Optimizing-Swift-Build-Times" \\
  || miss "origin remote is not fastred/Optimizing-Swift-Build-Times (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "assets/test.swift" \\
  && ok "assets/test.swift" \\
  || miss "missing critical file: assets/test.swift"
test -f "assets/compilation-and-optimization@2x.png" \\
  && ok "assets/compilation-and-optimization@2x.png" \\
  || miss "missing critical file: assets/compilation-and-optimization@2x.png"
test -f "assets/time@2x.png" \\
  && ok "assets/time@2x.png" \\
  || miss "missing critical file: assets/time@2x.png"
test -f "assets/active-arch@2x.png" \\
  && ok "assets/active-arch@2x.png" \\
  || miss "missing critical file: assets/active-arch@2x.png"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2685 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2655d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/fastred/Optimizing-Swift-Build-Times"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A curated collection of practical techniques and build configuration strategies for reducing Swift compilation times in Xcode projects. It documents compiler optimizations (Incremental Compilation Mode, Whole Module Optimization toggle), type-checking diagnostics flags, code profiling methods, and architectural patterns that directly impact Debug and Release build performance for medium-to-large iOS/macOS applications. Flat documentation structure: README.md as main content hub with table-of-contents sections, supported by illustrative assets in /assets/ (PNG diagrams and test.swift example file). Each section (Incremental Compilation Mode, Type checking, etc.) is self-contained with citations to official WWDC videos and external blog posts.

iOS and macOS developers working on large Swift codebases who experience slow compile cycles during development. Specifically: junior engineers learning build optimization best practices, team leads configuring project-wide build settings, and anyone frustrated with Xcode's Debug build times waiting for incremental recompilation.

This is an actively maintained educational reference (not a software library). It has a clear single maintainer (Arek Holko), focuses on documentation and visual assets rather than code, and covers battle-tested techniques from WWDC sessions and community experience. Maturity verdict: stable educational resource, not tied to specific software versions but evergreen in nature.

Low technical risk since this is a documentation repo with no dependencies or deployment surface. Single-maintainer model means documentation may fall behind Swift compiler changes in major Xcode releases. The advice is specific to Xcode 10+ (referenced in README), so recommendations may become outdated if Apple fundamentally changes build system internals.

Repository appears to be in maintenance mode—focused on preserving proven optimization patterns rather than active feature development. The README explicitly invites issues and PRs for missing content, suggesting the maintainer actively curates contributions rather than driving new major changes.

This is a documentation repository, not a runnable project. Clone and read: git clone https://github.com/fastred/Optimizing-Swift-Build-Times.git && cat README.md (or view directly on GitHub). No installation, dependencies, or build steps required.

Daily commands: Not applicable—this is a read-only documentation resource. Open README.md in any Markdown viewer or browse GitHub web interface. To apply recommendations: open an Xcode project, navigate to Build Settings, and apply the flags and configuration values documented in README sections.

• README.md — Primary entry point containing the complete Swift build optimization guide and methodology that all contributors must understand.
• assets/test.swift — Example Swift code demonstrating compilation issues and type-checking problems referenced throughout the optimization guide.
• assets/compilation-and-optimization@2x.png — Core visual explaining the compilation-optimization tradeoff strategy central to the project's recommendations.
• assets/time@2x.png — Benchmark visualization showing build time measurements that validate the optimization techniques proposed.
• assets/active-arch@2x.png — Architecture selection guide essential for understanding the 'Build active architecture only' optimization technique.
• LICENSE — Licensing terms governing usage and contribution rights for this optimization knowledge repository.

• Incremental Compilation Configuration (Swift compiler, Xcode build settings) — Control whether Swift compiler rebuilds only changed files or entire target; fundamental to debug build performance
  • Failure mode: If disabled, every build recompiles entire codebase regardless of changes; build times regress to full compilation baseline
• Type Checker Analysis (Swift compiler diagnostics, Xcode build log inspection) — Identify complex expressions and functions causing slow type inference; target for code refactoring
  • Failure mode: If type checking bottlenecks ignored, compilation remains slow even with other optimizations applied
• Build Architecture Selection (Xcode scheme configuration, build settings) — Optimize for active development platform (arm64 for Apple Silicon, x86_64 for Intel) rather than universal binaries
  • Failure mode: If building for all architectures during development, unnecessary compilation occurs for unused platforms
• Modularization Strategy (Xcode project structure, framework targets) — Decompose monolithic targets into framework dependencies to enable parallel compilation and incremental builds
  • Failure mode: Lack of modularization prevents parallelization and forces recompilation of monolithic targets on any change
• Build System Selection (Xcode build system configuration) — Use new Xcode build system for better parallelization and incremental compilation compared to legacy system
  • Failure mode: Using legacy build system loses parallelization benefits and forces sequential compilation

• Developer code changes → Incremental compiler — Modified Swift source files trigger differential compilation of dependent targets
• Type inference analysis → Build bottleneck identification — Complex expressions and functions identified as slow type-checking candidates for refactoring
• Build configuration settings → Compilation parameters — Xcode scheme and target build settings control optimization level, dSYM generation, active architecture selection
• Framework modularization → Parallel compilation queue — Independent framework targets can compile in parallel rather than sequential monolithic target compilation
• Build time measurements → Optimization technique validation — Benchmarks and visual assets demonstrate impact of each optimization technique relative to baseline

Add a new Swift build optimization technique

1. Add a new section header in the README.md table of contents (README.md)
2. Write the optimization technique explanation in the corresponding section of README.md with examples and measurements (README.md)
3. If the technique requires visual clarification, add a screenshot or diagram to the assets folder (e.g., assets/technique-name@2x.png) (assets/)
4. If relevant, create or update an example Swift file or Xcode configuration reference in assets/ (assets/test.swift)

Document a build configuration improvement

1. Add the configuration approach to the appropriate section in README.md (e.g., under 'Xcode Schemes') (README.md)
2. Create a screenshot showing the Xcode UI settings in assets/ with descriptive naming (assets/)
3. Reference the visual asset in the README.md section with context on why this configuration improves build times (README.md)

Add benchmark or comparative data

1. Create a visualization or timing diagram in assets/ (e.g., assets/benchmark-result@2x.png) (assets/)
2. Embed the asset in README.md with measured results and interpretation of what the data shows (README.md)
3. Provide context on test environment and methodology in the README section referencing the benchmark (README.md)

• Markdown documentation — Plain text format maximizes accessibility, version control friendliness, and contribution ease for a knowledge-base repository
• PNG screenshots and diagrams — Visual demonstration of Xcode UI configurations and build flow diagrams provides clarity that text alone cannot achieve
• GitHub repository hosting — Enables community contribution, version tracking, and discoverability for Swift developers seeking build optimization guidance

• Static documentation vs dynamic tooling

  • Why: Repository focuses on advice and patterns rather than providing automated tools to measure and optimize
  • Consequence: Developers must manually apply recommendations and measure impact themselves; lower barrier to understanding but higher implementation burden

• Comprehensive guide vs focused narrow scope

  • Why: Covers multiple optimization techniques (compilation modes, modularization, schemes, dSYM, etc.) rather than single issue
  • Consequence: Serves broad audience but readers must cherry-pick relevant techniques for their specific project bottlenecks

• Descriptive guidance vs code-based examples

  • Why: Primarily text and screenshots rather than runnable Swift code samples or build scripts
  • Consequence: Lower friction to read and understand but requires manual translation of concepts into project-specific configuration

• Not a build automation tool or CI/CD system
• Does not provide automated build time measurement infrastructure
• Not language-agnostic (Swift-specific guidance only)
• Does not replace Xcode or provide alternative build systems
• Not a third-party dependency manager (CocoaPods/SPM guidance only, not implementation)

• Complex expression type inference (High) — assets/test.swift: Swift compiler struggles with complex chained method calls and inline expressions; refactor into intermediate typed variables for faster compilation
• Building universal binaries in development (High) — README.md (Build active architecture only section): Compiling for all architectures during active development wastes time; configure schemes to build only for current platform
• Generating dSYM in Debug configuration (Medium) — README.md (dSYM generation section): Debug symbol generation adds significant build time overhead when not debugging; disable for Debug builds and enable selectively
• Full optimization in Debug builds — README.md (Incremental Compilation Mode section): Swift optimizer adds substantial time to builds without debugging benefit; use -Onone

No hidden traps for a documentation repo. However: advice assumes Xcode 10+ (referenced in README); older Xcode versions had different optimal settings (Whole Module Optimization for Debug was historically recommended). No CI/CD setup to validate that recommended settings actually work—verification is manual per-project. The -Xfrontend compiler flags are undocumented/unstable and may change between Swift versions without notice.

• Incremental Compilation Mode — Core Swift compiler mode that this repo recommends for Debug builds; enables rebuilding only changed files instead of entire module, directly addressing the 'long compile times' problem
• Whole Module Optimization (WMO) — Historical workaround for slow Debug builds (now obsolete); still recommended for Release builds in this repo to enable cross-function optimizations and dead-code elimination
• Type Checking Cost Analysis — Swift's sophisticated type inference system is the primary cause of slow compilation; this repo teaches profiling type-checking time per function/expression to identify bottlenecks
• dSYM (Debug Symbols) Generation — Build artifact that slows Debug builds but essential for production crash symbolication; this repo documents when to disable during development and re-enable for release
• Modularization / Framework Splitting — Architectural practice to partition code into independent frameworks, reducing recompilation scope when individual modules change; foundational strategy mentioned in this repo
• Compiler Diagnostic Flags (-Xfrontend) — Undocumented Swift compiler introspection flags (-warn-long-function-bodies, -warn-long-expression-type-checking) that this repo uses to expose type-checking hotspots
• Active Architecture Only Build Setting — Build optimization to compile only for the running simulator/device architecture during Debug, skipping unused architectures; reduces build time when not shipping to multiple targets

• SwiftFormat/SwiftFormat — Code style tool that can be integrated into build pipeline; poor formatting sometimes correlates with compilation issues and code clarity
• apple/swift — Official Swift compiler repo; source of truth for compiler flags, optimization passes, and build system changes referenced in this repo
• realm/realm-swift — Large real-world Swift library that documents its own compile-time optimization practices and performance testing CI setup
• johnno1962/Build-Time-Analyzer-for-Xcode — Complementary Xcode plugin that visualizes and profiles compile times per-file, enabling data-driven optimization decisions described in this repo
• Carthage/Carthage — Dependency manager affecting build modularization and link time; alternative to CocoaPods that can impact incremental compilation strategy

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Complete the truncated 'Use the new Xcode b...' section in README.md

The README.md file ends mid-sentence in the Table of Contents with 'Use the new Xcode b' which appears to be cut off. This section is incomplete and the corresponding content section is missing from the document. Completing this section would provide guidance on an important optimization topic (likely 'Use the new Xcode build system') that's referenced but never explained.

• [ ] Review the git history or similar Swift build optimization resources to determine the intended section title
• [ ] Complete the Table of Contents entry in README.md
• [ ] Add the full explanatory section with details, rationale, and potentially reference the assets/new_build_system@2x.png image
• [ ] Verify the section flows logically with surrounding content about modularization and XIB optimization

Create a structured benchmarking guide with the test.swift asset

The assets folder contains test.swift but there's no documentation explaining what this test file is for, how to use it, or what metrics it measures. This asset appears to be a concrete tool for measuring build times but lacks accompanying documentation. Adding a 'Benchmarking Your Build Times' section would help contributors validate their optimizations.

• [ ] Document the purpose and contents of assets/test.swift in README.md
• [ ] Add a new section titled 'Benchmarking Your Build Times' explaining how to use test.swift
• [ ] Include instructions on how to measure compilation time before and after applying optimizations
• [ ] Add example output or expected results to guide users in interpreting their findings

Add specific troubleshooting section for type checking bottlenecks

The Table of Contents references 'Type checking of functions and expressions' as a major section, but based on the file structure, there's likely minimal content explaining how to diagnose and fix type-checking slowdowns. This is a known pain point in Swift compilation. Adding concrete examples and diagnostic techniques would add significant value.

• [ ] Expand the 'Type checking of functions and expressions' section in README.md with diagnostic commands
• [ ] Include specific Xcode compiler flags and how to use swift -frontend type-checking diagnostics
• [ ] Add real-world examples of slow type-checking patterns (e.g., complex closure inference, long operator chains)
• [ ] Reference or create diagnostic output examples showing how to identify problematic code sections

• Add Xcode 15+ build system optimizations: Document Apple's recent Swift 5.9+ parallelization improvements and -driver-compare-debug-info flag (not currently mentioned in README): README stops at Xcode 10 and lacks recent compiler innovations
• Create a 'Modularization' section diagram: assets/modularization@2x.png showing dependency graph example and how framework splitting reduces recompilation scope: Table of contents references 'Modularization' but section content is sparse; visual examples like other sections would help
• Add a troubleshooting checklist: 'Compilation Times Still Slow?' section with decision tree (Is it incremental build? Check swiftc stats? Profile with XCTestDynamicOverlay?) referencing existing sections: README explains individual techniques but lacks guidance on which to apply first for maximum impact

This repository is a documentation/advisory project on Swift build optimization with minimal security risk. No production code, dependencies, secrets, or infrastructure components were detected. The codebase consists primarily of markdown documentation and image assets. No injection risks, hardcoded credentials, or misconfiguration issues were identified. The only minor considerations are standard best practices for any public repository.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.