Xcode Build Fixer

1---2name: xcode-build-fixer3description: Apply approved Xcode build optimization changes following best practices, then re-benchmark to verify improvement. Use when a developer has an approved optimization plan from xcode-build-orchestrator, wants to apply specific build fixes, needs help implementing build setting changes, script phase guards, source-level compilation fixes, or SPM restructuring that was recommended by an analysis skill.4---5 6# Xcode Build Fixer7 8Use this skill to implement approved build optimization changes and verify them with a benchmark.9 10## Core Rules11 12- Only apply changes that have explicit developer approval.13- Apply one logical fix at a time so changes are reviewable and reversible.14- Re-benchmark after applying changes to verify improvement.15- Report exactly what changed, which files were touched, and the measured delta.16- If a change produces no improvement or causes a regression, flag it immediately.17 18## Inputs19 20The fixer expects one of:21 22- An approved optimization plan at `.build-benchmark/optimization-plan.md` with checked approval boxes.23- An explicit developer instruction describing the fix to apply (e.g., "set `DEBUG_INFORMATION_FORMAT` to `dwarf` for Debug").24 25When working from an optimization plan, read the approval checklist and implement only the checked items.26 27## Fix Categories28 29### Build Settings30 31Change `project.pbxproj` values to match the recommendations in [build-settings-best-practices.md](references/build-settings-best-practices.md).32 33Typical fixes:34 35- Set `DEBUG_INFORMATION_FORMAT = dwarf` for Debug36- Set `SWIFT_COMPILATION_MODE = singlefile` for Debug37- Enable `COMPILATION_CACHE_ENABLE_CACHING = YES`38- Enable `EAGER_LINKING = YES` for Debug39- Align cross-target settings to eliminate module variants40 41When editing `project.pbxproj`, locate the correct `buildSettings` block by matching the target name and configuration name. Verify the change with `xcodebuild -showBuildSettings` after applying.42 43### Script Phases44 45Fix run script phases that waste time during incremental or debug builds.46 47Typical fixes:48 49- Add input and output file declarations so Xcode can skip unchanged scripts.50- Add configuration guards: `[[ "$CONFIGURATION" != "Release" ]] && exit 0` for release-only scripts.51- Move input/output lists into `.xcfilelist` files when the list is long.52- Enable `Based on dependency analysis` when inputs and outputs are declared.53 54### Source-Level Compilation Fixes55 56Apply code changes that reduce type-checker and compiler overhead. See [references/fix-patterns.md](references/fix-patterns.md) for before/after patterns.57 58Typical fixes:59 60- Add explicit type annotations to complex expressions.61- Break long chained or nested expressions into intermediate typed variables.62- Mark classes `final` when they are not subclassed.63- Tighten access control (`private`/`fileprivate`) for internal-only symbols.64- Extract monolithic SwiftUI `body` properties into smaller composed subviews.65- Replace deeply nested result-builder code with separate typed helpers.66- Add explicit return types to closures passed to generic functions.67 68### SPM Restructuring69 70Restructure Swift packages to improve build parallelism and reduce rebuild scope.71 72Typical fixes:73 74- Move shared types to a lower-layer module to eliminate circular or upward dependencies.75- Split oversized modules (200+ files) by feature area.76- Extract protocol definitions into lightweight interface modules.77- Remove unnecessary `@_exported import` usage.78- Align build options across targets that import the same packages to prevent module variant duplication.79- Pin branch-tracked dependencies to tagged versions or commit hashes for deterministic resolution.80 81Before applying version pin changes:82 83- Run `git ls-remote --tags <url>` to confirm tags exist. If the upstream has no tags, pin to a specific revision hash instead.84- Verify the pinned version resolves successfully with `xcodebuild -resolvePackageDependencies` before proceeding.85 86## Execution Workflow87 881. Read the approved optimization plan or developer instruction.892. For each approved item, identify the exact files and locations to change.903. Apply the change.914. Verify the change compiles: run a quick `xcodebuild build` to confirm no errors were introduced.925. After all approved changes are applied, re-benchmark using the same inputs from the original baseline:93   ```bash94   python3 scripts/benchmark_builds.py \95     --project App.xcodeproj \96     --scheme MyApp \97     --configuration Debug \98     --destination "platform=iOS Simulator,name=iPhone 16" \99     --output-dir .build-benchmark100   ```1016. Compare post-change medians to the baseline and report deltas.102 103## Evaluating Regressions104 105Not every slower number is a true regression. The fixer must evaluate the full picture before recommending a revert.106 107### Compilation caching trade-off108 109A change like `COMPILATION_CACHE_ENABLE_CACHING = YES` may make a standard clean build slightly slower (cache population overhead) while making cached clean builds significantly faster. Since cached clean builds reflect the realistic developer workflow (branch switching, pulling changes, Clean Build Folder with a warm cache), a slower standard clean build paired with a faster cached clean build is a net improvement, not a regression. The same logic applies to any change where the first-time cost is higher but subsequent builds benefit.110 111### Compare all build types112 113Evaluate standard clean, cached clean (when available), and incremental builds together. A change is only a clear regression if it makes the metrics that matter to the developer's daily workflow worse. If only the cold-start clean build is slower but the developer rarely does truly cold builds, that may be acceptable.114 115### Per-change vs. cumulative116 117A single change that regresses on its own may still be worth keeping if it enables a larger cumulative improvement (e.g., enabling compilation caching makes one build type slower but unlocks cache benefits for everything else).118 119### Best-practice settings are not revert candidates120 121Some build settings are Apple's recommended modern defaults. These should be applied and kept regardless of whether the immediate benchmark shows a measurable improvement. They are not speculative optimizations -- they align the project with Apple's toolchain direction and will compound in value over future Xcode releases. The fixer must never recommend reverting these settings based on a single benchmark result.122 123Best-practice settings that should always be kept once applied:124 125- `COMPILATION_CACHE_ENABLE_CACHING = YES` -- Apple is actively investing in this; the cache improves with each Xcode release and compounds across real workflows126- `EAGER_LINKING = YES` (Debug) -- allows the linker to overlap with compilation127- `SWIFT_USE_INTEGRATED_DRIVER = YES` -- eliminates inter-process scheduling overhead128- `DEBUG_INFORMATION_FORMAT = dwarf` (Debug) -- avoids unnecessary dSYM generation129- `SWIFT_COMPILATION_MODE = singlefile` (Debug) -- incremental recompilation130- `ONLY_ACTIVE_ARCH = YES` (Debug) -- no reason to build all architectures locally131 132When reporting on these settings, use language like: "Applied recommended build setting. No immediate benchmark improvement measured, but this aligns with Apple's recommended configuration and positions the project for future Xcode improvements."133 134### When to recommend revert (speculative changes only)135 136For changes that are not best-practice settings (e.g., source refactors, linkage experiments, script phase modifications, dependency restructuring):137 138- If the cumulative pass shows wall-clock regression across all measured build types (standard clean, cached clean, and incremental are all slower), recommend reverting all speculative changes unless the developer explicitly asks to keep specific items for non-performance reasons.139- For each individual speculative change: if it shows no median improvement and no cached/incremental benefit either, flag it with `Recommend revert` and the measured delta.140- Distinguish between "outlier reduction only" (improved worst-case but not median) and "median improvement" (improved typical developer wait).141- When a change trades off one build type for another (e.g., slower standard clean but faster cached clean), present both numbers clearly and let the developer decide. Frame it as: "Standard clean builds are X.Xs slower, but cached clean builds (the realistic daily workflow) are Y.Ys faster."142 143## Reporting144 145Lead with the wall-clock result in plain language:146 147> "Your clean build now takes X.Xs (was Y.Ys) -- Z.Zs faster."148> "Your incremental build now takes X.Xs (was Y.Ys) -- Z.Zs faster."149 150Then include:151 152- Post-change clean build wall-clock median153- Post-change incremental build wall-clock median154- Absolute and percentage wall-clock deltas for both155- Confidence notes if benchmark noise is high156- List of files modified per fix157- Any deviations from the original recommendation158 159If cumulative task metrics improved but wall-clock did not, say plainly: "Compiler workload decreased but build wait time did not improve. This is expected when Xcode runs these tasks in parallel with other equally long work."160 161If a fix produced no measurable wall-time improvement, note `No measurable wall-time improvement` and suggest whether to keep (e.g. for code quality) or revert.162 163For changes valuable for non-benchmark reasons (deterministic package resolution, branch-switch caching), label them: "No wait-time improvement expected from this change. The benefit is [deterministic builds / faster branch switching / reduced CI cost]."164 165Note: `COMPILATION_CACHE_ENABLE_CACHING` has been measured at 5-14% faster clean builds across tested projects (87 to 1,991 Swift files). The benefit compounds in real developer workflows where the cache persists between builds -- branch switching, pulling changes, and CI with persistent DerivedData. The benchmark script auto-detects this setting and runs a cached clean phase for validation.166 167## Execution Report168 169After the optimization pass is complete, produce a structured execution report. This gives the developer a clear summary of what was attempted, what worked, and what the final state is.170 171Structure:172 173```markdown174## Execution Report175 176### Baseline177- Clean build median: X.Xs178- Cached clean build median: X.Xs (if applicable)179- Incremental build median: X.Xs180 181### Changes Applied182 183| # | Change | Actionability | Measured Result | Status |184|---|--------|---------------|-----------------|--------|185| 1 | Description | repo-local | Clean: X.Xs→Y.Ys, Incr: X.Xs→Y.Ys | Kept / Reverted / Blocked |186| 2 | ... | ... | ... | ... |187 188### Final Cumulative Result189- Clean build median: X.Xs (was Y.Ys) -- Z.Zs faster/slower190- Cached clean build median: X.Xs (was Y.Ys) -- Z.Zs faster/slower191- Incremental build median: X.Xs (was Y.Ys) -- Z.Zs faster/slower192- **Net result:** Faster / Slower / Unchanged193 194### Blocked or Non-Actionable Findings195- Finding: reason it could not be addressed from the repo196```197 198Status values:199 200- `Kept` -- Change improved or maintained build times and was kept.201- `Kept (best practice)` -- Change is a recommended build setting; kept regardless of immediate benchmark result.202- `Reverted` -- Change regressed build times and was reverted.203- `Blocked` -- Change could not be applied due to project structure, Xcode behavior, or external constraints.204- `No improvement` -- Change compiled but showed no measurable wall-time benefit. Include whether it was kept (for non-performance reasons) or reverted.205 206## Escalation207 208If during implementation you discover issues outside this skill's scope:209 210- Project-level analysis gaps: hand off to [`xcode-project-analyzer`](../xcode-project-analyzer/SKILL.md)211- Compilation hotspot analysis: hand off to [`xcode-compilation-analyzer`](../xcode-compilation-analyzer/SKILL.md)212- Package graph issues: hand off to [`spm-build-analysis`](../spm-build-analysis/SKILL.md)213 214## Additional Resources215 216- For concrete before/after fix patterns, see [references/fix-patterns.md](references/fix-patterns.md)217- For build settings best practices, see [references/build-settings-best-practices.md](references/build-settings-best-practices.md)218- For the recommendation format, see [references/recommendation-format.md](references/recommendation-format.md)