// ZSH-XCODE-COMPLETIONS — ENGINEERING REPORT

Project-aware xcodebuild completion

Instead of static enum lists, _xcodebuild queries the current directory:

• -scheme <TAB> → xcodebuild -list output, sed-extracted between "Schemes:" and end
• -target <TAB> → xcodebuild -list, sed-extracted between "Targets:" and "Build Configurations:"
• -configuration <TAB> → same, between "Build Configurations:" and "If no build"
• -arch <TAB> → xcodebuild -showBuildSettings | grep VALID_ARCHS | cut -f 2 -d '='
• -project <TAB> → glob *.xcodeproj via _multi_parts /
• -workspace <TAB> → glob *.xcworkspace
• -xcconfig <TAB> → glob *.xcconfig

Cached SDK list (cross-tool)

Both _xcodebuild and _swift share the same SDK-cache idiom: _retrieve_cache SDKS → populate _installed_sdks via xcodebuild -showsdks → _store_cache SDKS. The cache key (SDKS) is shared across completers so a single SDK install/uninstall invalidates everywhere.

xcrun toolchain glob

xcrun --toolchain <TAB> → toolchains=(/Applications/Xcode*.app/Contents/Developer/Toolchains/*.xctoolchain) — glob over every installed Xcode's toolchains directory. Works with side-by-side Xcode installations (beta + release).

Instruments template cache

instruments -t <TAB> → _instruments_templates → _call_program templates 'instruments -s templates'. Output format is one quoted template per line with a "Known Templates" header. The completer uses ${(Q)${(f)...}} to split-by-line + strip-quotes, then shift template_list to drop the header. _retrieve_cache _instruments_templates persists the result so repeated TABs don't re-spawn instruments.

xcode-select Xcode picker

xcode-select --switch <TAB> → xcodes=(/Applications/Xcode*.app) → _values "Available Xcodes" $xcodes. Side-by-side Xcode versions are visible by glob, no enumeration of /Applications needed.

xcrun shim for nested tools

xcrun's design (xcrun <tool> <args>) hides nested tools from zsh's completion-system #compdef lookup — swift-demangle isn't directly on PATH, so _swift-demangle never fires. The shim at bin/swift-demangle (3-line POSIX sh wrapper running xcrun swift-demangle "$@") gives users a direct PATH binary that surfaces the completer. Homebrew offers --without-shims for users who don't want the wrapper.

11 separate #compdef files, not one mega-file

Each Xcode CLI tool is its own binary with its own flag surface; folding them into a single _xcode dispatcher would slow autoload and couple their lifecycles. Keeping 11 small #compdef files means zsh only loads the completer for the tool the user actually invokes — compinit-time cost is paid once and lazily-resolved per tool.

Live project queries, not static enums

Xcode schemes / targets / configurations / valid-archs differ per project. Hardcoding enums would be wrong the moment the user cds into a different repo. Instead, _xcodebuild shells out to xcodebuild -list / -showBuildSettings at completion time — cost is one xcodebuild spawn per TAB, but the result is project-correct.

Shim binary for xcrun nesting

xcrun's dispatch model breaks zsh's completion-system #compdef <binary> contract — nested tools aren't directly on PATH. The shim path (bin/swift-demangle = xcrun swift-demangle "$@") is the cleanest workaround: surface the tool as a PATH binary so the completer fires. Cost is one extra fork; benefit is autocomplete that Just Works.

Shared SDK cache key

Three completers (_xcodebuild, _swift, _xcrun) all need the SDK list. They share the cache key SDKS, so installing or uninstalling an SDK invalidates the cache for all three at once — no per-tool cache divergence. The cache key is plain SDKS (not prefix-keyed) because SDK lists are tiny and global.

1-line plugin entrypoint

The plugin file is literally fpath=("${0:h}/src" $fpath). No ZSH_ARGZERO self-locate because the plugin file lives at the repo root, and ${0:h} works correctly for direct sourcing. Zinit / OMZ / antibody all set $0 to the plugin file's path before sourcing — the 2-line idiom is unnecessary here. Less code, fewer pins, same outcome.