Xcode Compilation Analyzer

1---2name: xcode-compilation-analyzer3description: Analyze Swift and mixed-language compile hotspots using build timing summaries and Swift frontend diagnostics, then produce a recommend-first source-level optimization plan. Use when a developer reports slow compilation, type-checking warnings, expensive clean-build compile phases, long CompileSwiftSources tasks, warn-long-function-bodies output, or wants to speed up Swift type checking.4---5 6# Xcode Compilation Analyzer7 8Use this skill when compile time, not just general project configuration, looks like the bottleneck.9 10## Core Rules11 12- Start from evidence, ideally a recent `.build-benchmark/` artifact or raw timing-summary output.13- Prefer analysis-only compiler flags over persistent project edits during investigation.14- Rank findings by expected **wall-clock** impact, not cumulative compile-time impact. When compile tasks are heavily parallelized (sum of compile categories >> wall-clock median), note that fixing individual hotspots may improve parallel efficiency without reducing build wait time.15- When the evidence points to parallelized work rather than serial bottlenecks, label recommendations as "Reduces compiler workload (parallel)" rather than "Reduces build time."16- Do not edit source or build settings without explicit developer approval.17 18## What To Inspect19 20- `Build Timing Summary` output from clean and incremental builds21- long-running `CompileSwiftSources` or per-file compilation tasks22- `SwiftEmitModule` time -- can reach 60s+ after a single-line change in large modules; if it dominates incremental builds, the module is likely too large or macro-heavy23- `Planning Swift module` time -- if this category is disproportionately large in incremental builds (up to 30s per module), it signals unexpected input invalidation or macro-related rebuild cascading24- ad hoc runs with:25  - `-Xfrontend -warn-long-expression-type-checking=<ms>`26  - `-Xfrontend -warn-long-function-bodies=<ms>`27- deeper diagnostic flags for thorough investigation:28  - `-Xfrontend -debug-time-compilation` -- per-file compile times to rank the slowest files29  - `-Xfrontend -debug-time-function-bodies` -- per-function compile times (unfiltered, complements the threshold-based warning flags)30  - `-Xswiftc -driver-time-compilation` -- driver-level timing to isolate driver overhead31  - `-Xfrontend -stats-output-dir <path>` -- detailed compiler statistics (JSON) per compilation unit for root-cause analysis32- mixed Swift and Objective-C surfaces that increase bridging work33 34## Analysis Workflow35 361. Identify whether the main issue is broad compilation volume or a few extreme hotspots.372. Parse timing-summary categories and rank the biggest compile contributors.383. Run the diagnostics script to surface type-checking hotspots:39   ```bash40   python3 scripts/diagnose_compilation.py \41     --project App.xcodeproj \42     --scheme MyApp \43     --configuration Debug \44     --destination "platform=iOS Simulator,name=iPhone 16" \45     --threshold 100 \46     --output-dir .build-benchmark47   ```48   This produces a ranked list of functions and expressions that exceed the millisecond threshold. Use the diagnostics artifact alongside source inspection to focus on the most expensive files first.494. Map the evidence to a concrete recommendation list.505. Separate code-level suggestions from project-level or module-level suggestions.51 52## Apple-Derived Checks53 54Look for these patterns first:55 56- missing explicit type information in expensive expressions57- complex chained or nested expressions that are hard to type-check58- delegate properties typed as `AnyObject` instead of a concrete protocol59- oversized Objective-C bridging headers or generated Swift-to-Objective-C surfaces60- header imports that skip framework qualification and miss module-cache reuse61- classes missing `final` that are never subclassed62- overly broad access control (`public`/`open`) on internal-only symbols63- monolithic SwiftUI `body` properties that should be decomposed into subviews64- long method chains or closures without intermediate type annotations65 66## Reporting Format67 68For each recommendation, include:69 70- observed evidence71- likely affected file or module72- expected wait-time impact (e.g. "Expected to reduce your clean build by ~2s" or "Reduces parallel compile work but unlikely to reduce build wait time")73- confidence74- whether approval is required before applying it75 76If the evidence points to project configuration instead of source, hand off to [`xcode-project-analyzer`](../xcode-project-analyzer/SKILL.md) by reading its SKILL.md and applying its workflow to the same project context.77 78## Preferred Tactics79 80- Suggest ad hoc flag injection through the build command before recommending persistent build-setting changes.81- Prefer narrowing giant view builders, closures, or result-builder expressions into smaller typed units.82- Recommend explicit imports and protocol typing when they reduce compiler search space.83- Call out when mixed-language boundaries are the real issue rather than Swift syntax alone.84 85## Additional Resources86 87- For the detailed audit checklist, see [references/code-compilation-checks.md](references/code-compilation-checks.md)88- For the shared recommendation structure, see [references/recommendation-format.md](references/recommendation-format.md)89- For source citations, see [references/build-optimization-sources.md](references/build-optimization-sources.md)