xcode-defaults: a command list for Xcode's undocumented preference keys

What problem a list of defaults write commands actually solves

Xcode exposes a Preferences window that covers a fraction of its behaviour. The rest lives in the macOS user defaults domain com.apple.dt.Xcode, plus com.apple.dt.XCBuild for the build system and com.apple.iphonesimulator for the Simulator. Apple does not publish most of those keys. The repository collects commands that write them, each with a one-line description of the intended effect. The audience is narrow: developers who already know what defaults write does and want a starting point rather than a GUI. It suits people debugging build times, indexer failures or Assistant behaviour, and it assumes you are comfortable with the idea that you are changing software behaviour through an unsupported interface. Nothing here installs a binary. There is no package, no CLI and no configuration file. The artifact is prose plus shell commands.

How the commands reach Xcode: the user defaults domain

Every command in the README follows the same shape: defaults write <domain> <key> <value>. The domain is usually com.apple.dt.Xcode, sometimes com.apple.dt.XCBuild, once com.apple.iphonesimulator. The value is a boolean, an integer, a string or, in one case, an array append. macOS stores these in the plist at ~/Library/Preferences/com.apple.dt.Xcode.plist, which is the same file the README tells you to back up with defaults read com.apple.dt.Xcode > ~/Desktop/XcodeDefaults.plist. That is the whole mechanism. There is no wrapper that validates a key before writing it, and no schema that rejects a typo. If you misspell a key, the write succeeds and Xcode ignores it. The README leans on this by documenting the restore path as deletion rather than as a set of inverse commands: kill Xcode, move the plist aside, and reopen the app so it writes a fresh one. The repository layout is a single README plus a GitHub Actions workflow named Check Markdown links, which is consistent with a documentation-only project whose automated check is link validity, not command correctness.

The build and indexing keys worth understanding before you type them

The most consequential entries concern the build system. EnableSwiftBuildSystemIntegration is described as opting into a mode introduced with Xcode 13.3 that, per the linked release notes, uses available cores better for Swift projects. BuildSystemScheduleInherentlyParallelCommandsExclusively and its counterpart BuildSystemScheduleInherentlyParallelCommandsSerially control whether Swift build tasks run alongside other commands; the README notes that parallel scheduling may improve build times and may also increase memory use. Two keys set concurrency limits by shelling out to sysctl -n hw.ncpu: IDEBuildOperationMaxNumberOfConcurrentCompileTasks and PBXNumberOfParallelBuildSubtasks. Both write the raw CPU thread count, which is a blunt default on a machine that is also running a simulator and a browser. The indexing keys are the ones with visible side effects. Disabling indexing requires deleting the opposite key first, because IDEIndexEnable and IDEIndexDisable are separate booleans rather than one toggle. The README states plainly that disabling indexing also disables the refactor code action, so protocol conformances and memberwise initializers stop being generated. That is a real cost, not a footnote. For diagnosis there are IDEIndexerActivityShowNumericProgress, IDEIndexShowLog, IDEShowPrebuildLogs and IDESourceKitServiceLogLevel, the last of which the README says may not work anymore and offers an environment-variable alternative: SOURCEKIT_LOGGING=3 /Applications/Xcode.app/Contents/MacOS/Xcode.

Getting a working set in place, command by command

Start with the backup the README gives: defaults read com.apple.dt.Xcode > ~/Desktop/XcodeDefaults.plist. Then apply keys individually rather than as a block, so you can attribute a behaviour change to one write. A reasonable first pass is the visibility keys, which are low risk: defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES, defaults write com.apple.dt.Xcode PegasusMultipleCursorsEnabled -bool YES for multi-cursor editing, and defaults write com.apple.dt.Xcode ShowDVTDebugMenu -bool YES for the internal debug menu. If you use the Assistant heavily, the array append is the one command that adds rather than replaces: defaults write com.apple.dt.Xcode IDEAdditionalCounterpartSuffixes -array-add "ViewModel" "View" "Screen". Because it appends, running it twice duplicates entries; the README gives no removal command, so you would edit the plist or delete the key. Two keys exist to stop Xcode restoring state: ApplePersistenceIgnoreState and IDEDisableStateRestoration, the first described as enabling multiple Xcode versions for different projects. For toolchain paths there are IDEHomebrewPrefixPath, which takes a string from brew --prefix, and IDEClonedSourcePackagesDirPathOverride, which the README maps to xcodebuild's clonedSourcePackagesDirPath option. To undo everything, follow the restore section: killall Xcode, then mv ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Desktop/XcodeDefaults.plist, then open -b com.apple.dt.Xcode. That moves the file rather than deleting it, so the old state is still on disk if you change your mind.

Where the reference sheet runs out

The biggest limitation is that none of these keys is a public API. The README itself concedes the point for at least one entry, noting that IDESourceKitServiceLogLevel may not work anymore. A key that Xcode stops reading fails silently: the write returns success, the plist changes, and nothing else happens. That makes the repository hard to trust as a specification and easier to treat as a set of hypotheses to test per Xcode version. There is no version matrix, no minimum Xcode version per key beyond the two places where release notes are linked, and no changelog, since no releases were retrieved. The build-debugging key is explicitly self-defeating for daily use: EnableBuildDebugging is described as slowing the build system and littering DerivedData/<project>/Build/Intermediates.noindex, and the README says it should generally be enabled only when capturing a trace for incremental build debugging. Two other entries are footguns rather than features. DVTDisableMainThreadChecker turns off a runtime checker that catches UI work off the main thread, which is a debugging aid you lose. IDEDisableStructureEditingCoordinator stops files moving when you restructure a project, which is the opposite of what many people expect from a project file. And the concurrency keys write hw.ncpu without any cap, so on a laptop under memory pressure you may trade build time for swapping. This is the wrong tool if you want reproducible, versioned developer environment setup. It is also the wrong tool for anyone who does not want to reason about which keys their Xcode build actually reads.

A real alternative: provisioning profiles and a script you control

The nearest alternative in kind is not another defaults list but a configuration-management layer such as Nix with nix-darwin or a chezmoi-managed dotfiles repository. The difference is in what gets recorded. This repository records commands, which you run by hand and which leave no trace of what you applied. A dotfiles or Nix setup records the desired state of the plist and reapplies it, so a new machine converges to the same preferences and you can see in version control when a key was added. The cost is that you must transcribe every key from this README into your own configuration format and keep it current yourself, because the project ships no module, formula or profile to import. A second alternative is to skip the defaults entirely and use the Xcode Preferences UI where an option exists, accepting that some of these keys (the indexing logs, the SourceKit log level, the Homebrew prefix) have no UI at all. The README's own structure points at the gap: it is a list of one-shot commands, and the only state-management advice it gives is to back up the plist and to delete it to start over.

Maintenance cost and the CC BY-ND 4.0 badge

The repository was last pushed in August 2026 and carries no retrieved releases, so there is no versioned artifact to pin. Maintenance is therefore on you: each time Xcode updates, the keys you rely on may stop being read, and the only way to know is to test the observable effect. The workflow in the repository checks Markdown links, not whether the commands still do anything, so a green badge says nothing about key validity. On licensing, the README displays a CC BY-ND 4.0 badge, while the repository metadata reports NOASSERTION, which means the automated licence detection could not classify it. CC BY-ND 4.0 permits sharing with attribution and does not permit distributing modified versions. For a documentation repository that matters if you plan to copy the command list into internal documentation and edit it, since the NoDerivatives term restricts that. I am not a lawyer and this is not legal advice; read the licence text at the link in the badge if redistribution is part of your plan. For personal use, copying commands into your own shell history or notes is the ordinary case, and the practical cost is simply re-verifying keys after major Xcode upgrades.

Editorial conclusion

Adopt this as a personal reference if you already edit Xcode preferences from the terminal and want a starting list of keys for build parallelism, indexing logs and Assistant counterpart suffixes. Do not adopt it as a team-wide provisioning mechanism: the README gives no script, no version gating and no uninstall path, and several keys are flagged as possibly dead. Before applying anything, run defaults read com.apple.dt.Xcode > ~/Desktop/XcodeDefaults.plist so you can diff and restore, and check the CC BY-ND 4.0 badge against how you intend to redistribute the text.

Official sources

1. ctreffs/xcode-defaults on GitHub
2. Issues
3. Project website
4. README