What does an Xcode scheme control, how do test plans and derived data fit in, and how do you use xcodebuild and simulators when something is wrong?

A scheme says what to build and what to do with it, and has an action per task: Build (which targets), Run (which build configuration, the launch arguments, environment variables and the Diagnostics tab where sanitizers, Zombie Objects, Main Thread Checker and Malloc Stack Logging are switched on), Test (which tests, and the test plan), Profile (Instruments, usually a Release configuration), Analyze and Archive. Many “it behaves differently” problems are scheme differences: a different configuration, an argument set on one machine, a sanitizer on, or a shared versus personal scheme (check the shared scheme into source control so everyone and CI use the same one). A test plan (.xctestplan) moves test configuration into a file: which tests, the language and region, environment, code coverage, parallelism, random order and repeat-on-failure, and several configurations of the same tests.

Derived data is where Xcode puts intermediate build products, indexes and logs for each project (by default under ~/Library/Developer/Xcode/DerivedData). It is a cache, so deleting a project’s folder (or the lot) is safe and fixes a long list of strange problems: stale modules, “no such module” after a branch switch, a corrupted index that breaks autocomplete or navigation; the cost is a full rebuild, so do not do it reflexively, and find out why if it recurs. From the command line xcodebuild -list shows the schemes and targets (for a Swift package it generates a scheme such as Lib-Package, as the check below shows), -showBuildSettings prints the resolved settings (Q369), -derivedDataPath puts the cache somewhere clean for CI, build-for-testing and test-without-building separate building from testing, and -resultBundlePath keeps the evidence. For simulators, xcrun simctl lists, boots, erases and resets devices (Erase All Content and Settings clears a bad state), and Window ▸ Devices and Simulators manages devices, runtimes and logs. If a build breaks mysteriously, change one thing at a time: clean the build folder, then derived data, then the simulator state, then check the toolchain and Xcode version.