Building and Shipping Mac and iOS Apps Without Ever Opening Xcode A developer describes a workflow for building and shipping Mac and iOS apps entirely from the command line, using XcodeGen and Apple's command-line tools, without ever opening Xcode's GUI. The process requires Xcode to be installed and a one-time GUI setup for Apple ID and certificates, after which builds, signing, notarization, and deployment are fully automated via scripts. Building and Shipping Mac and iOS Apps Without Ever Opening Xcode /building-and-shipping-mac-and-ios-apps-without-ever-opening-xcode Lately, I’ve heard several Apple related podcasters talk about how bad Xcode is, and how Apple needs to make vibe-coding Mac and iOS apps better by making Xcode less inscrutable. They’re not wrong, but also I don’t understand why they’re even opening Xcode in the first place. With a little bit of pre-work, you can vibe code Mac and iOS apps to your heart’s content without looking at Xcode anymore. And if you’re ever in doubt about how to make any of the following work, point Claude Code or your LLM coding tool of choice to this blog post, and let it figure it out. That’s literally its job, figuring out things you don’t want to have to. TL;DR Xcode.app must be installed, but it never has to be open. xcodebuild , notarytool , stapler , and devicectl all live inside Xcode and run fine from a shell. A few one-time steps do need the GUI or an interactive terminal : sign into your Apple ID, create a Developer ID certificate, store a notarization password. After that, builds and deploys are fully headless. The Mac app ships via one script — scripts/release.sh — which you write once. It runs the whole chain: archive → Developer ID sign → notarize → staple → install to /Applications . Signing is certificate-and-keychain based. The signing key lives in the login keychain; xcodebuild finds it automatically. No secrets in the repo. The one-time setup is the only part with any friction, so let’s get it out of the way first. Install Xcode You do have to have Xcode installed, there’s no getting around that, because build depends on tools that live inside Xcode.app. Once Xcode is installed, make sure it’s the selected command line toolchain, and not /Library/Developer/CommandLineTools . If the output of the check is /Applications/Xcode.app/Contents/Developer , you’re in good shape: If it DOES return the path for the standalone CommandLineTools instead, point it to Xcode intead. NOTE: The name “Command Line Tools” can be confusing. This is because there’s a standalone Command Line Tools package, available with xcode-select --install , which is the /Library/Developer/CommandLineTools version. This contains clang and git, but not the iOS SDK, notarytool, devicectl, and other items needed for full app development. The complete toolchain is inside Xcode.app, at /Applications/Xcode.app/Developer , and it has everything you need. If you have Xcode installed, you don’t need the standalone Command Line Tools. Install XcodeGen Xcode and its command line tools aren’t enough to generate and manage Xcode projects automatically. For that, you’re going to need XcodeGen https://xcodegen.com/ . You can download it from Github https://github.com/yonaskolb/XcodeGen or install it using homebrew: Long story short, Xcode projects are actually folders that macOS makes appear as files, and they contain everything about your project needed to create and compile your app. Xcode constantly modifies the files and file references constantly, and it creates issues for git repositories. Xcodegen creates a project.yml YAML file with all your project settings, and then on every build, it recreates the entire .xcodeproj folder using that project.yml file. Only the YAML file has to be committed to git, and the whole .xcodeproj can be ignored from git’s perspective. Configure Xcode, Once You do need to setup Xcode initially in order to never have to look at it again. Xcode License and Additional Components First, either accept its license and install its additional components, or do it through the command line: Setup Your Apple Developer Account in Xcode Next, open Xcode, click on Settings → Accounts and click on + to add your account. NOTE: You have to have a paid Apple Developer account in order to distribute and notarize your apps. And you will want them notarized in order to install them on you Mac and iOS devices and not have the OSes decided they’re malware and delete them. Create a Developer ID Application Certificate Once that’s done, create a Developer ID Application certificate Settings → Accounts → your Apple ID → Manage Certificates… → + → Developer ID Application , which creates a cert for signing the shipped .app bundle. Please note that a Developer ID Application certificate and your Apple Development certificate are two separate things. The Apple Development identity is for building and running on your own devices — pushing to your iPhone, local debugging. The Developer ID Application identity is for the notarized .app that survives Gatekeeper and runs on someone else’s Mac. The release script wants that second one. Creating the certificate in Xcode installs both the certificate and its private key into your login keychain. That private key is what actually does the signing, and it cannot be re-downloaded — so don’t delete it, and back up your keychain. When in doubt, ask your LLM of choice about them and have it help you get set up. It’s the one that’s going to be using Xcode for you anyway. And finally, Store a Notarization Credential – Once, in Terminal Notarization uploads your signed app to Apple for a malware scan. notarytool authenticates using a stored keychain profile that you create once, interactively — it prompts for an app-specific password, and there’s no way around the prompt: A few things worth knowing here: Name the profile after the app. Don’t borrow another app’s profile — it’ll work on your machine and then silently break on someone else’s. The app-specific password is not your Apple ID password. Generate one at appleid.apple.com https://appleid.apple.com → Sign-In & Security → App-Specific Passwords . These passwords go stale silently whenever you change your Apple ID password. A 401 invalid credentials out of notarization almost always means “go make a fresh app-specific password,” not “your setup is broken.” Confirm it’s stored: Side topic here, I store my app-specific passwords in a 1Password vault that Claude Code has access to. That way whenever I’m creating a new app, I can tell IT to create the notarization credential for me, and it knows to check its 1Password vault for the password. The whole point of using the LLM in the first place is to avoid doing things manually that you don’t want to do. Setup a Local.xconfig File and Add It to .gitignore Real signing needs your team ID and bundle prefix, and I put those in a Local.xconfig file: Again, if in doubt, ask Claude Code or your LLM of choice to create this for you. Set up the Agent Tools Create the Deploy Script Deployment on my apps is handled via a script called release.sh that lives in a scripts folder inside the repo. Without it, I don’t have an automated build pipeline. I had Claude Code create mine: I told Claude, more or less: I want to archive, Developer ID-sign, notarize, staple, and install this app to /Applications without ever opening Xcode. Write me a script that does the whole chain and fails loudly if any step breaks. It didn’t need me to explain the pipeline, because the pipeline isn’t a secret — archive with xcodebuild , export with -exportArchive and an ExportOptions.plist , submit with notarytool --wait , attach the ticket with stapler , check with spctl . That’s the documented, conventional way to ship a Developer ID Mac app, and the model knows it. What it needed from me was the project-specific stuff: the scheme name, the team ID, what to call the notary profile, where to install the result. Then it wrote a first draft, we ran it, it broke, and we fixed it. That loop is not a failure mode, it’s just the process. I always look at AI workflows as works in progress, but it doesn’t take long before you can stop tweaking things and just start working. This is the actual script from one of my app repos: It looks more complicated than it is, but it is a series of steps that you’d have to know need performed. Again, this is why you talk to your LLM, tell it what you want, and have it help build your workflow. Some things to note: set -euo pipefail halts the script on any failing command immediately instead of blundering forward. There’s no half-finished state that looks like success. cd "$ dirname "$0" /.." means the script hops to the repo root regardless of where you invoked it from, so ./scripts/release.sh works whether you’re in the repo root or three directories down. The pre-flight block checks that xcodegen exists and that the notary profile is actually stored before spending five minutes on an archive that’s doomed to fail at step five. And the last two steps re-verify the installed bundle, not just the exported one. Belt and suspenders, but I’ve had a copy step silently mangle a bundle before and I’d rather find out from the script than from Gatekeeper three days later when it deletes my app for me. Create CLAUDE.md or AGENTS.md release.sh gives you a one-command deploy. CLAUDE.md or AGENTS.md for basically every other model under the sun is what makes the agent actually use it without being told every single time. I had Claude create my CLAUDE.md itself after going back and forth about the build process. Now whenever I create a new app, I tell it to reference the repo for one of my other apps and use the same methodology. That’s It And that’s the whole one-time setup. From here on, nothing needs a mouse. How the build actually runs — no GUI in the loop Everything below is plain command-line invocation. Xcode.app never launches; these tools live inside it but run standalone. This is exactly what Claude Code executes through its shell. Fast, Unsigned Checks For “does it compile / do the tests pass,” you don’t need signing at all: CODE SIGNING ALLOWED=NO gives you an ad-hoc build: it compiles and runs in a simulator, but Gatekeeper rejects it and entitlements like iCloud KVS and App Group don’t bind. That’s the fast inner loop. The Mac Release Pipeline One command does the entire shippable chain — the script from Part two: Archive, Developer ID export, notarize, staple, verify, install. If any step fails it stops and tells you which one broke. Need a different notary profile? Override it: TZED NOTARY PROFILE=