Ship Mac & iOS Apps Without Xcode Using CLI Tools

For many developers, opening Xcode feels like boarding a slow ferry when you just need to cross the street. The IDE is powerful, no doubt, but it's also notorious for being resource-hungry, opinionated, and occasionally just... broken. A growing movement in the Apple developer community is pushing back: build, test, and ship Mac and iOS apps entirely from the terminal, never touching Xcode's GUI at all.

This isn't fringe experimentation anymore. Developers are doing it in production, and the tooling has matured enough to make it genuinely practical.

Why Ditch the Xcode GUI?

The appeal is straightforward. Terminal-based workflows are faster to script, easier to automate, and far more CI/CD-friendly. When your entire build process lives in shell scripts or Makefiles, spinning up a GitHub Actions runner or a Buildkite agent becomes trivial. There's no need to maintain a macOS machine with a specific Xcode version just to click through a GUI.

There's also a cognitive load argument. Many developers find that staying in the terminal—where they're already writing code, running tests, and managing Git—reduces context switching. Jumping into Xcode's project navigator, build settings panels, and organizer windows breaks the flow that a pure keyboard-driven environment maintains.

The Core Toolchain

Apple ships a suite of command-line tools that do the heavy lifting Xcode's GUI wraps around:

xcodebuild is the foundation. It compiles Swift and Objective-C projects, runs tests, and produces archives—all from the terminal. Combined with a well-structured .xcodeproj or Swift Package, you can drive your entire build pipeline with a single command.

Swift Package Manager (SPM) has dramatically reduced dependence on Xcode project files altogether. For many apps, especially those without complex asset catalogs or storyboards, SPM can define the entire project structure. You edit Package.swift in any text editor, build with swift build, and test with swift test.

xcrun acts as a toolchain proxy, letting you invoke Apple SDKs and tools without hard-coding paths. It adapts to whichever Xcode Command Line Tools version is active on the system, which is handy in multi-environment CI setups.

altool and notarytool handle App Store submission and notarization. The newer notarytool (introduced with Xcode 13) made the notarization process dramatically faster and more scriptable than the old approach.

Editors That Fill the Gap

Without Xcode, you need somewhere to actually write code. VS Code with the Swift extension has become a popular choice, offering syntax highlighting, code completion via SourceKit-LSP, and integrated terminal access. Neovim and Helix users have also embraced SourceKit-LSP for a fully modal, fast editing experience.

For UI work, the tradeoff is real. SwiftUI previews live inside Xcode, and you lose them in a pure CLI workflow. Some developers work around this by keeping a minimal Xcode install purely for occasional preview checks, while doing all actual development and shipping through the terminal.

Automation and CI/CD Payoffs

This is where the CLI-first approach really shines. A typical GitHub Actions pipeline for an iOS app can look like this:

xcodebuild clean build test \
  -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 15' \
  CODE_SIGNING_ALLOWED=NO

Combine that with fastlane for certificate management and App Store uploads, and you have a fully automated pipeline that requires zero human interaction after a git push. Pull request checks, TestFlight uploads, and App Store releases can all flow from a single merge.

Where AI APIs Fit In

If you're building an AI-powered Mac or iOS app—think on-device summarization, natural language search, or a chatbot interface—integrating an LLM API is often part of the stack. A CLI-first workflow pairs naturally here: your API keys, model configurations, and endpoint URLs live in environment variables, making it easy to swap between providers or test against different models in CI.

Services like KodaAPI simplify this further. Instead of managing separate API keys for OpenAI, Anthropic, Google Gemini, and DeepSeek, you use one unified key across 100+ models. In a scripted build environment where secrets management already matters, consolidating API credentials is a genuine operational win—fewer secrets to rotate, fewer integration points to break.

Is It for Everyone?

Honestly, no. Developers who rely heavily on Interface Builder, Instruments profiling, or Core Data model editors will find the GUI genuinely useful. The CLI-first approach is best suited for Swift-first, SwiftUI-driven apps with clean package structures.

But for those who fit that profile, the workflow gains are real. Faster builds, reproducible environments, scriptable everything, and the quiet satisfaction of shipping an app without Xcode ever stealing your entire screen.

Inspired by scottwillsey.com