Xcode Build Fixer
Audit Xcode Debug and Release build settings against a performance-focused checklist so Swift/iOS projects compile faster during iteration.
Overview
xcode-build-fixer is an agent skill most often used in Ship (also Build) that audits Xcode build settings for compile-time performance and outputs a pass/fail checklist.
Install
npx skills add https://github.com/avdlee/xcode-build-optimization-agent-skill --skill xcode-build-fixerWhat is this skill?
- Pass/fail audit scoped strictly to build-performance settings—not Swift language migration flags
- Documents Debug recommendations: `SWIFT_COMPILATION_MODE` singlefile, `SWIFT_OPTIMIZATION_LEVEL` -Onone, `GCC_OPTIMIZATI
- Each setting includes recommended value, why it matters, and change risk
- Reporting format uses [x] / [ ] with actual vs expected values
- Release configuration guidance included for production-appropriate optimization tradeoffs
- Checklist uses explicit [x]/[ ] indicators per setting
- Scope excludes SWIFT_STRICT_CONCURRENCY and SWIFT_UPCOMING_FEATURE_* flags
Adoption & trust: 2.4k installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Swift/Xcode project rebuilds too much on every save and you do not know which build settings are slowing iteration.
Who is it for?
Solo builders shipping native Apple apps who want faster local and CI compile loops without changing language-adoption flags.
Skip if: Teams seeking runtime app performance profiling, App Store metadata work, or Swift 6 concurrency migration advice—the skill explicitly excludes those settings.
When should I use this skill?
Xcode compile times feel wrong, after inheriting a project, or when preparing build-performance fixes for Debug/Release configurations.
What do I get? / Deliverables
You get a structured pass/fail report mapping each performance-related key to recommended Debug/Release values so you can apply fixes in Xcode or project files.
- Pass/fail build-settings checklist with actual vs recommended values
- Per-setting risk notes for proposed changes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship/perf because the skill optimizes compile time and build throughput before you scale CI or cut release cycles. Build-settings tuning (incremental vs whole module, -Onone in Debug) directly affects how fast you ship fixes on device and simulator.
Where it fits
After cloning a SwiftUI app, run the audit before your first week of feature work so Debug stays incremental.
CI macOS runners time out on compile—align Release optimization with the reference before adding more hardware.
Maintenance branch compile regressions—re-check settings someone flipped to wholemodule during a hotfix.
How it compares
Use instead of generic “clean build folder” habits when the root cause is mis-set compilation and optimization levels.
Common Questions / FAQ
Who is xcode-build-fixer for?
Indie and solo iOS/macOS developers using Xcode who want an agent-guided audit of build-performance settings, not a full project rewrite.
When should I use xcode-build-fixer?
During Ship/perf when compile times spike after merging, when onboarding to an inherited `.xcodeproj`, or in Build/devops prep before tightening CI pipelines for Apple targets.
Is xcode-build-fixer safe to install?
It is documentation and checklist guidance; changing build settings can affect build times and binary behavior—review the Security Audits panel on this page and test Debug/Release builds after edits.
SKILL.md
READMESKILL.md - Xcode Build Fixer
# Build Settings Best Practices This reference lists Xcode build settings that affect build performance. Use it to audit a project and produce a pass/fail checklist. The scope is strictly **build performance**. Do not flag language-migration settings like `SWIFT_STRICT_CONCURRENCY` or `SWIFT_UPCOMING_FEATURE_*` -- those are developer adoption choices unrelated to build speed. ## How To Read This Reference Each setting includes: - **Setting name** and the Xcode build-settings key - **Recommended value** for Debug and Release - **Why it matters** for build time - **Risk** of changing it Use checkmark and cross indicators when reporting: - `[x]` -- setting matches the recommended value - `[ ]` -- setting does not match; include the actual value and the expected value ## Debug Configuration These settings optimize for fast iteration during development. ### Compilation Mode - **Key:** `SWIFT_COMPILATION_MODE` - **Recommended:** `singlefile` (Xcode UI: "Incremental"; or unset -- Xcode defaults to singlefile for Debug) - **Why:** Single-file mode recompiles only changed files. `wholemodule` recompiles the entire target on every change. - **Risk:** Low ### Swift Optimization Level - **Key:** `SWIFT_OPTIMIZATION_LEVEL` - **Recommended:** `-Onone` - **Why:** Optimization passes add significant compile time. Debug builds do not benefit from runtime speed improvements. - **Risk:** Low ### GCC Optimization Level - **Key:** `GCC_OPTIMIZATION_LEVEL` - **Recommended:** `0` - **Why:** Same rationale as Swift optimization level, but for C/C++/Objective-C sources. - **Risk:** Low ### Build Active Architecture Only - **Key:** `ONLY_ACTIVE_ARCH` (`BUILD_ACTIVE_ARCHITECTURE_ONLY`) - **Recommended:** `YES` - **Why:** Building all architectures doubles or triples compile and link time for no debug benefit. - **Risk:** Low ### Debug Information Format - **Key:** `DEBUG_INFORMATION_FORMAT` - **Recommended:** `dwarf` - **Why:** `dwarf-with-dsym` generates a separate dSYM bundle which adds overhead. Plain `dwarf` embeds debug info directly in the binary, which is sufficient for local debugging. - **Risk:** Low ### Enable Testability - **Key:** `ENABLE_TESTABILITY` - **Recommended:** `YES` - **Why:** Required for `@testable import`. Adds minor overhead by exporting internal symbols, but this is expected during development. - **Risk:** Low ### Active Compilation Conditions - **Key:** `SWIFT_ACTIVE_COMPILATION_CONDITIONS` - **Recommended:** Should include `DEBUG` - **Why:** Guards conditional compilation blocks (e.g., `#if DEBUG`) and ensures debug-only code paths are included. - **Risk:** Low ### Eager Linking - **Key:** `EAGER_LINKING` - **Recommended:** `YES` - **Why:** Allows the linker to start work before all compilation tasks finish, reducing wall-clock build time. Particularly effective for Debug builds where link time is a meaningful fraction of total build time. - **Risk:** Low ## Release Configuration These settings optimize for production builds. ### Compilation Mode - **Key:** `SWIFT_COMPILATION_MODE` - **Recommended:** `wholemodule` - **Why:** Whole-module optimization produces faster runtime code. Build time is secondary for release. - **Risk:** Low ### Swift Optimization Level - **Key:** `SWIFT_OPTIMIZATION_LEVEL` - **Recommended:** `-O` or `-Osize` - **Why:** Produces optimized binaries. `-Osize` trades some speed for smaller binary size. - **Risk:** Low ### GCC Optimization Level - **Key:** `GCC_OPTIMIZATION_LEVEL` - **Recommended:** `s` - **Why:** Optimizes C/C++/Objective-C for size, matching the typical release expectation. - **Risk:** Low ### Build Active Architecture Only - **Key:** `ONLY_ACTIVE_ARCH` - **Recommended:** `NO` - **Why:** Release builds must include all supported architectures for distribution. - **Risk:** Low ### Debug Information Format - **Key:** `DEBUG_INFORMATION_FORMAT` - **Recommended:** `dwarf-with-dsym` - **Why:** dSYM bundles are required for crash symbolication in productio