Ship Mac and iOS Apps From the Command Line, No Xcode GUI Required

Apple’s Xcode has drawn complaints from developers who find it opaque and ill-suited to LLM-assisted coding. Scott Willsey’s counterargument is simpler: stop opening it. Xcode.app must be installed because the real build tooling lives inside it, but the binaries that matter—xcodebuild, notarytool, stapler, and devicectl—all run fine from a shell. Once you point xcode-select at the full toolchain rather than the standalone Command Line Tools package (which lacks the iOS SDK and notarization tools), the GUI becomes optional.

The setup has a one-time friction cost that can’t be scripted away: signing into an Apple ID, creating a Developer ID Application certificate, and storing an app-specific password for notarytool all require the GUI or an interactive prompt. Willsey flags the usual traps—the Developer ID certificate is distinct from the Apple Development identity, the signing private key can’t be re-downloaded so the login keychain needs backing up, and app-specific passwords silently expire whenever the Apple ID password changes, surfacing as a cryptic 401 during notarization. XcodeGen rounds out the workflow by generating the messy .xcodeproj bundle from a single committed project.yml, keeping Xcode’s constant file churn out of git.

After setup, everything runs headless through one release.sh script that chains archive, Developer ID signing, notarization, stapling, and install to /Applications. The broader point is a workflow philosophy: because that pipeline is the documented, conventional way to ship a Developer ID Mac app, an LLM like Claude Code already knows it and only needs the project-specific details—scheme name, team ID, notary profile. Willsey even stores app-specific passwords in a 1Password vault the model can read, treating the AI as the thing that operates Xcode’s tooling so the developer never has to.