
Xcode Project Analyzer
Analyze an Xcode workspace or project and surface Apple-aligned fixes when incremental builds feel slow or wasteful.
Overview
Xcode Project Analyzer is an agent skill most often used in Build (also Ship performance tuning and Operate iteration) that reviews your Xcode project against Apple’s build-efficiency guidance and outputs prioritized str
Install
npx skills add https://github.com/avdlee/xcode-build-optimization-agent-skill --skill xcode-project-analyzerWhat is this skill?
- Anchors advice to Apple docs on incremental build speed, coding efficiency, and explicit module dependencies
- Recommends measuring first with Build With Timing Summary or xcodebuild -showBuildTimingSummary
- Audits run-script input/output declarations and .xcfilelist usage so Xcode can skip unnecessary work
- Checks module maps, DEFINES_MODULE, and consistent compile options for framework reuse
- Surfaces Swift/Obj-C patterns: framework-qualified imports, narrow bridging, simpler type-checking hot spots
- Run-script phases should declare inputs and outputs; .xcfilelist supports many path entries
- Enabling DEFINES_MODULE supports module maps for custom frameworks and libraries
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?
Small code changes trigger huge Xcode rebuilds and you cannot tell whether targets, scripts, modules, or Swift typing habits are the bottleneck.
Who is it for?
Solo builders maintaining Swift or mixed Swift/Objective-C Xcode apps who want incremental-build wins grounded in Apple documentation.
Skip if: Teams without an Xcode/macOS toolchain, greenfield apps with no build pain yet, or anyone expecting automated refactors without you applying and re-measuring changes locally.
When should I use this skill?
Xcode incremental builds are slow, unpredictable, or CI compile time is climbing and you want Apple-aligned project analysis before changing structure.
What do I get? / Deliverables
You get a measured-first checklist of Apple-aligned changes—dependencies, script I/O, modules, and import patterns—so the next build cycle targets real incremental-build waste.
- Prioritized build-optimization findings tied to Apple documentation topics
- Action list for targets, run scripts, module settings, and import or bridging habits
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because recommendations target project structure, targets, modules, and scripts—the work you do while the app is actively being compiled and integrated. Integrations fits Xcode toolchain wiring: target dependencies, run-script phases, xcfilelists, module maps, and xcodebuild timing—not UI feature work.
Where it fits
You are splitting a monolithic app target and want dependency and module guidance before merging the refactor.
Release week compile times block repeated archive builds, so you need script I/O and module reuse fixes before signing.
CI queues grow after each PR and you re-run the analyzer against the latest timing summary to prioritize the next maintenance PR.
How it compares
Use this structured project review instead of random Build Settings tweaks or generic “clean derived data” advice.
Common Questions / FAQ
Who is xcode-project-analyzer for?
It is for solo and indie developers shipping Apple-platform apps in Xcode who need a systematic read on why incremental builds are slow.
When should I use xcode-project-analyzer?
Use it during Build when restructuring targets or adding scripts; during Ship when tuning performance before release; and during Operate when CI or local compile times keep growing after small commits—always after capturing a timing summary.
Is xcode-project-analyzer safe to install?
Treat it like any third-party agent skill: review the Security Audits panel on this Prism page and only grant shell or filesystem access you are comfortable with for xcodebuild and project inspection.
SKILL.md
READMESKILL.md - Xcode Project Analyzer
# Build Optimization Sources This file stores the external sources that the README and skill docs should cite consistently. ## Apple: Improving the speed of incremental builds Source: - <https://developer.apple.com/documentation/xcode/improving-the-speed-of-incremental-builds> Key takeaways: - Measure first with `Build With Timing Summary` or `xcodebuild -showBuildTimingSummary`. - Accurate target dependencies improve correctness and parallelism. - Run scripts should declare inputs and outputs so Xcode can skip unnecessary work. - `.xcfilelist` files are appropriate when scripts have many inputs or outputs. - Custom frameworks and libraries benefit from module maps, typically by enabling `DEFINES_MODULE`. - Module reuse is strongest when related sources compile with consistent options. - Breaking monolithic targets into better-scoped modules can reduce unnecessary rebuilds. ## Apple: Improving build efficiency with good coding practices Source: - <https://developer.apple.com/documentation/xcode/improving-build-efficiency-with-good-coding-practices> Key takeaways: - Use framework-qualified imports when module maps are available. - Keep Objective-C bridging surfaces narrow. - Prefer explicit type information when inference becomes expensive. - Use explicit delegate protocols instead of overly generic delegate types. - Simplify complex expressions that are hard for the compiler to type-check. ## Apple: Building your project with explicit module dependencies Source: - <https://developer.apple.com/documentation/xcode/building-your-project-with-explicit-module-dependencies> Key takeaways: - Explicit module builds make module work visible in the build log and improve scheduling. - Repeated builds of the same module often point to avoidable module variants. - Inconsistent build options across targets can force duplicate module builds. - Timing summaries can reveal option drift that prevents module reuse. ## SwiftLee: Build performance analysis for speeding up Xcode builds Source: - <https://www.avanderlee.com/optimization/analysing-build-performance-xcode/> Key takeaways: - Clean and incremental builds should both be measured because they reveal different problems. - Build Timeline and Build Timing Summary are practical starting points for build optimization. - Build scripts often produce large incremental-build wins when guarded correctly. - `-warn-long-function-bodies` and `-warn-long-expression-type-checking` help surface compile hotspots. - Typical debug and release build setting mismatches are worth auditing, especially in older projects. ## Apple: Xcode Release Notes -- Compilation Caching Source: - Xcode Release Notes (149700201) Key takeaways: - Compilation caching is an opt-in feature for Swift and C-family languages. - It caches prior compilation results and reuses them when the same source inputs are recompiled. - Branch switching and clean builds benefit the most. - Can be enabled via the "Enable Compilation Caching" build setting or per-user project settings. ## Apple: Demystify explicitly built modules (WWDC24) Source: - <https://developer.apple.com/videos/play/wwdc2024/10171/> Key takeaways: - Explains how explicitly built modules divide compilation into scan, module build, and source compile stages. - Unrelated modules build in parallel, improving CPU utilization. - Module variant duplication is a key bottleneck -- uniform compiler options across targets prevent it. - The build log shows each module as a discrete task, making it easier to diagnose scheduling issues. ## Swift Compile-Time Best Practices Well-known Swift language patterns that reduce type-checker workload during compilation: - Mark classes `final` when they are not intended for subclassing. This eliminates dynamic dispatch overhead and allows the compiler to de-virtualize method calls. - Restrict access control to the narrowest useful scope (`private`, `fileprivate`). Fewer visible symbols reduce the compiler's search sp