For any Xcode project or Swift Package Manager package, use this order — pick the first option that fits the situation, do not skip down the list. #
Xcode MCP Tools— use these when Xcode has the project open. They reuse the running Xcode's build state (no duplicate DerivedData / build caches piling up), and open the door to workflows the CLI cannot reach — running screenshot / snapshot tests through the running IDE, driving simulators the user is already using, etc. -
— for CLI builds and tests. Compiles bundled resources correctly:xcodebuild
.xcstrings
string catalogs become per-locale.strings
inside the bundle,.xcassets
are compiled, etc. Use this when Xcode is not open or when a headless build is needed. -
— last resort. Only safe for pure-Swift packages with no resources.swift build
/swift test
They cannot resolve bundled resources. A.xcstrings
file is copied intoBundle.module
but never compiled into per-locale.strings
, so at runtimeString(localized:bundle:)
returns the raw key and every test that asserts on translated text fails..xcassets
has the equivalent problem for image lookups. If a Package declaresresources: [.process("Resources")]
with anything more than plain data files,swift test
will silently fail resource-dependent tests — reach forxcodebuild
instead.