ctreffs/xcode-defaults: a command-line reference for tuning Xcode without the GUI

What ctreffs/xcode-defaults actually is

Xcode keeps a large amount of behaviour in user defaults that have no checkbox in the Preferences window. Some of them are documented in release notes, some are mentioned once in a conference talk, and some are passed around on social media. This repository collects those keys into a single Markdown file, one short section per key, each with the exact defaults write command and, where the original author knew it, a source link.

The audience is narrow. You need to be comfortable running defaults write against com.apple.dt.Xcode and com.apple.dt.XCBuild, and you need to accept that these are undocumented or semi-documented keys. The README does not present itself as a supported product. It is a list, and the value is in the key names and the exact syntax, not in any code the repository ships. There is no binary, no package manifest and no build step: the top-level entries are .github/, LICENSE.md and README.md.

How the defaults mechanism works and where the settings land

Every command in the list writes into the same macOS preference domain, com.apple.dt.Xcode, or into com.apple.dt.XCBuild for build-system keys. The values are stored in ~/Library/Preferences/com.apple.dt.Xcode.plist, which is why the backup section of the README is a plain defaults read redirect and the restore section is a file move.

That single-file model explains most of the caveats. Settings are global to your user account, not per project. They survive Xcode updates because the plist is separate from the application bundle, but they also survive uninstalling Xcode, which is why a stale key can sit around for years. Some keys are read by the IDE process, others by the build system, and a few are read by the Simulator under com.apple.iphonesimulator. Changing a build-system key such as EnableSwiftBuildSystemIntegration has no effect until the next build, while IDE keys generally need Xcode restarted.

The list also mixes two kinds of entry. Boolean toggles are straightforward: ShowBuildOperationDuration, PegasusMultipleCursorsEnabled, IDEIndexDisable. Numeric settings are computed at write time, for example IDEBuildOperationMaxNumberOfConcurrentCompileTasks is set to the output of sysctl -n hw.ncpu, so the value is frozen at whatever your machine reported that day. If you move to a different Mac, that number does not follow your hardware.

Backing up, restoring and running your first defaults command

The README opens with a backup step, and it is the right place to start. This writes the entire current Xcode preference domain to a plist on your Desktop, so you have a copy before you change anything.

defaults read com.apple.dt.Xcode > ~/Desktop/XcodeDefaults.plist

After running it, open the file or grep it to see which keys you already have set. A fresh Xcode install produces a small plist; a machine that has been in use for years can carry a long tail of keys you forgot about.

The restore path in the README does not write values back. It quits Xcode, moves the plist out of the way, and lets Xcode regenerate a fresh one on next launch.

killall Xcode
mv ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Desktop/XcodeDefaults.plist
open -b com.apple.dt.Xcode

The README states that if you delete or move the current plist, Xcode writes a fresh one the next time you run it. Note the destination path in that snippet is the same file name used by the backup command, so if you run both in sequence you overwrite your backup. Pick a different path for the restore move.

For a first real change, the build-time display is the least risky entry in the list because it only affects what Xcode shows you.

defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES

Restart Xcode and run a build. The README describes this key as enabling project build time, so the effect should appear in the build log or the activity area rather than in the editor.

The build parallelism keys and what they cost you

The most consequential entries are the ones that change how much work the build system runs at once. The README documents four separate mechanisms, and they are not interchangeable.

BuildSystemScheduleInherentlyParallelCommandsExclusively and BuildSystemScheduleInherentlyParallelCommandsSerially are a matched pair. The first enables parallel builds for Swift, the second disables them. The README explains the context directly: Xcode 9.3 began running more Swift build tasks in parallel with other commands, which may improve build times and may also increase memory use during the build. That is a real trade-off on machines with limited RAM, and the two keys exist precisely so you can turn it off again.

IDEBuildOperationMaxNumberOfConcurrentCompileTasks and PBXNumberOfParallelBuildSubtasks both take a thread count, and the README sets both from sysctl -n hw.ncpu. Setting the maximum to the full thread count is aggressive. On a laptop that is also running a simulator, a test runner and a browser, oversubscribing the CPU can make the whole session feel worse even if the compile step itself finishes sooner. The list gives you the syntax but no guidance on a sensible value, which is a gap if you are tuning rather than copying.

EnableSwiftBuildSystemIntegration is a different kind of switch. The README ties it to Xcode 13.3, where the build system and Swift compiler gained a mode that better utilizes available cores, and notes that the mode is opt-in and can be enabled globally. Because it is opt-in, the default is off, and turning it on changes compiler behaviour rather than just scheduling.

Indexing, logging and the keys that slow Xcode down

Several entries trade performance or stability for visibility. IDESourceKitServiceLogLevel set to 3 makes SourceKit write a log to /tmp with details of what it is doing while indexing. The README notes that a lot of people find header hygiene or module problems this way, that the setting may not work anymore, and that you can get the same effect for one session by prepending SOURCEKIT_LOGGING=3 to the Xcode binary path. The self-reported uncertainty is worth taking seriously: the repository is a collection of tips, and the author does not claim each one still applies to current Xcode.

EnableBuildDebugging is documented with an explicit warning. The README says it slows down the build system and litters DerivedData/<project>/Build/Intermediates.noindex, and that it should generally only be enabled when capturing a trace for incremental build debugging. That is the clearest example of a key you enable for one investigation and then remove.

The indexing keys carry a functional cost that is easy to miss. The README states that disabling indexing will disable the refactor code action, so you probably will not be able to generate protocol conformances or memberwise initializers. Turning off indexing to stop the indexer from competing for CPU removes editor features you may depend on, and there is no partial mode documented here. The enable and disable sections are written as pairs of commands: each one deletes the opposite key before writing its own, which is the correct pattern because a leftover key can override the new value depending on read order.

Where the list is thin, and what to use instead

The repository is a reference sheet, so the honest comparison is against the alternatives to copying commands out of a README.

Xcode itself exposes some of these settings in Preferences and in the scheme and build settings editors. Build settings live in the project or workspace, travel with the repository, and apply per target, which is the opposite of the global plist approach here. If the setting you want already exists as a build setting, that is the better home for it because your teammates get it automatically. The keys in this list are the ones that have no build-setting equivalent, which is exactly why they ended up in a README.

For repeatable machine setup, a configuration-management tool that writes defaults declaratively is a better fit than a list of shell commands. The README gives no script, no dotfile and no way to apply a subset, so automating this repository means transcribing commands into your own tooling and owning the key names yourself. There is no versioning of individual entries, no deprecation markers, and no test that would catch a key that stopped working in a new Xcode release.

A third option is to not change these defaults at all. Several entries exist to work around behaviour that Apple may have changed since the tip was written. The README already flags this for the SourceKit log level, and the same risk applies to any key sourced from a social media post rather than release notes.

Maintenance, licensing and the cost of upgrading Xcode

The last push to the repository was on 2026-08-11, so it is not abandoned, but the commit history is not the thing that determines whether a given key still works. Xcode releases change which defaults are read. Nothing in the repository pins entries to Xcode versions except where the prose mentions one, such as the Xcode 13.3 note on EnableSwiftBuildSystemIntegration or the Xcode 9.3 note on parallel Swift builds.

The practical upgrade cost is that after a major Xcode update you should re-check any key you rely on. The README does not document a verification procedure, so the only check available is to read the key back and observe the behaviour, or to compare against a fresh plist generated by the restore steps above.

The license is listed as NOASSERTION in the repository metadata, and the README badge points to CC BY-ND 4.0. CC BY-ND permits redistribution but not derivative works, which matters if you were planning to fork the list, edit it and publish your own version. Copying individual commands into internal documentation is a different question from republishing a modified collection, and the repository does not spell out which it considers acceptable. Treat the badge as the stated license and check it yourself before redistributing anything derived from the file.

Editorial conclusion

Adopt ctreffs/xcode-defaults if you already edit Xcode preferences from the terminal and want the exact key names for build parallelism, indexing and state restoration in one place. Skip it if you expect a script, a CLI or a way to apply settings per project; every entry is a manual defaults command against the global com.apple.dt.Xcode domain. Before running anything, back up the plist with defaults read com.apple.dt.Xcode > ~/Desktop/XcodeDefaults.plist, then verify each key you plan to use by reading it back with defaults read com.apple.dt.Xcode <key> after the write.

Frequently asked questions

Official sources

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