xcode-debugging

BUILD FAILED errors with no details typically stem from stale Derived Data, zombie xcodebuild processes, or stuck simulator states rather than code issues. Clean Derived Data, terminate zombie processes using `ps aux | grep -E "xcodebuild|Simulator"`, and rebuild to resolve 80% of these cases in minutes.

"No such module" errors after Swift Package Manager updates often indicate stale build artifacts. Delete Derived Data, terminate any running xcodebuild or Simulator processes, reset the simulator if needed, then perform a clean rebuild to restore module availability.

Simulator hangs and boot failures usually result from zombie Simulator processes or corrupted simulator state. Identify stuck processes with `ps aux | grep Simulator`, terminate them, reset the simulator, and verify Derived Data isn't excessively large before attempting a fresh boot.

Intermittent failures without code changes indicate environment drift—stale Derived Data, zombie xcodebuild processes, or simulator state corruption. Apply environment-first diagnostics: clean Derived Data, purge zombie processes, reset simulators, then rebuild and retest.

Yes. This approach applies to both iOS and macOS projects facing BUILD FAILED, test crashes, simulator hangs, or module errors. Environment-first diagnostics work across platforms by targeting Derived Data, xcodebuild processes, and simulator state—core issues independent of platform specifics.

Prioritize environment checks before debugging code: verify Derived Data size, enumerate and terminate zombie xcodebuild and Simulator processes, inspect simulator states, then execute standardized cleanup and rebuild sequences. This systematic approach resolves most mysterious failures faster than code-level debugging.