Apple developers have long relied on Xcode as the central hub for building applications for Mac, iPhone, and iPad. Yet a growing number of engineers now complete entire projects from start to finish without ever launching the graphical IDE. Scott Willsey explored this approach in detail on his personal site, sharing concrete techniques that let programmers stay inside familiar text editors and command-line tools while still producing production-ready apps.
The method begins with a clear separation between project creation and code editing. Instead of generating a project through Xcode’s template wizard, developers initialize a Swift package using the Swift Package Manager directly from the terminal. Running `swift package init –type executable` creates the basic directory structure with a Sources folder and a Package.swift manifest. This file serves as the single source of truth for dependencies, targets, and build settings, replacing the .xcodeproj file entirely.
Once the package exists, engineers add an Xcode project wrapper only when absolutely necessary. The command `swift package generate-xcodeproj` produces a minimal project file that Xcode can open if a visual debugger or Interface Builder session becomes unavoidable. Most of the time, however, the project remains untouched. Code lives in ordinary Swift files, edited inside Vim, Neovim, Emacs, or any editor with Swift language server support. SourceKit-LSP provides autocompletion, type checking, and inline diagnostics without requiring the full Xcode application.
Building the app happens through straightforward terminal commands. `swift build` compiles the package, while `swift run` executes the resulting binary. For iOS and macOS apps that need to be bundled as .app packages, additional steps integrate the Swift compiler output with the necessary Info.plist, entitlements, and asset catalogs. A simple Makefile or shell script automates these tasks, copying resources into the correct directory structure and signing the bundle with `codesign`. The entire process stays within a few lines of script that can be version-controlled alongside the source.
Interface design presents the most obvious challenge when avoiding Xcode. Storyboards and XIB files traditionally require Interface Builder, yet modern SwiftUI eliminates much of this dependency. Because SwiftUI views are defined entirely in code, developers write declarative user interfaces directly in their text editor. Live previews can be triggered through a separate SwiftUI preview canvas that runs independently of Xcode by using the `swift run` command with a small helper target. For UIKit projects that still require nib files, engineers generate the XML manually or maintain a single Xcode project solely for editing those files before extracting the resulting XIB and checking it into source control.
Testing follows the same command-line philosophy. The `swift test` command discovers and runs XCTest suites without launching the simulator or the full IDE. Continuous integration servers can therefore validate pull requests using nothing more than a Docker container with the Swift toolchain installed. This approach reduces CI costs and simplifies the pipeline, since the build environment matches the developer’s local terminal exactly.
Distribution requires additional tooling but remains fully scriptable. For macOS applications, the `productbuild` and `pkgutil` commands create installer packages, while `notarytool` handles submission to Apple’s notary service for Gatekeeper approval. iOS apps follow a similar path using `xcodebuild` in headless mode when signing and archiving become necessary. Although `xcodebuild` technically invokes components from Xcode, it runs from the command line and does not require opening the graphical interface. Many developers wrap these calls inside a fastlane lane or custom bash function so the process feels like a single `make release` command.
Dependency management benefits enormously from this workflow. The Package.swift file supports both Swift Package Manager dependencies and binary targets, removing the need for CocoaPods or Carthage in many cases. When a project does require an Xcode-specific framework, engineers declare it as a binary target that points to a pre-compiled .xcframework downloaded during the build. This keeps the main development loop inside the terminal while still consuming libraries that ship only as binary artifacts.
Debugging without Xcode surprises many experienced developers. LLDB works perfectly from the command line through the `lldb` executable. Setting breakpoints, inspecting variables, and stepping through code all remain available using the same commands familiar to anyone who has debugged C or C++ programs. For visual debugging of UI state, developers often attach Instruments or the Console app directly to the running process. The lack of a graphical variables view is offset by the speed of iterating changes: edit a Swift file, hit save, run a one-line build script, and the updated application launches within seconds.
Performance profiling follows the same pattern. The `swift run –enable-testing` flag combined with Instruments’ command-line interface allows measurement of CPU, memory, and energy usage without ever seeing Xcode’s scheme editor. Automation scripts can even generate HTML reports that developers review in their browser of choice.
Team collaboration improves when everyone follows the same lightweight workflow. New contributors clone the repository, run `make bootstrap` to install dependencies, and immediately begin editing code without waiting for Xcode to index hundreds of files. Merge conflicts become simpler because Package.swift is a readable text file rather than an opaque plist inside an .xcodeproj bundle. Build times drop because incremental compilation happens at the module level rather than through Xcode’s more complex dependency graph.
Learning this approach does require comfort with the command line and a willingness to replace visual tools with code. Yet the payoff appears quickly. Build scripts become part of the project documentation, making onboarding faster. Reproducible builds reduce the classic “it works on my machine” problem. And the ability to develop on remote machines or lightweight laptops without Xcode’s substantial resource requirements opens new possibilities for developers working in constrained environments.
Many engineers maintain a hybrid setup. They keep Xcode installed for occasional needs such as provisioning profile management or App Store Connect screenshots, but they never open the application during day-to-day coding. A single keystroke in their editor triggers a build-and-run task that compiles, launches the simulator or app, and attaches the debugger automatically. The experience feels closer to web development workflows where saving a file instantly refreshes the browser.
The Swift community continues to expand command-line support. Tools like Mint for installing command-line utilities, Tuist for managing large Xcode projects from configuration files, and XcodeGen for generating project files from YAML all reduce reliance on the graphical IDE. Apple’s own swift-driver project improves compiler performance for command-line builds, while ongoing work on SwiftPM aims to add native support for resource bundling and code signing in future releases.
Security-conscious teams appreciate the transparency of a text-based build system. Every step of the compilation and packaging process can be audited through readable scripts rather than opaque GUI actions. Code signing certificates and entitlements live in version-controlled files instead of hidden inside Xcode’s project settings. This visibility helps organizations meet compliance requirements more easily.
The transition does not happen overnight. Most developers begin by creating a small utility application entirely with SwiftPM, then gradually move larger personal projects to the same model. Once comfortable, they introduce the workflow to team projects, often starting with shared libraries before tackling the main application target. Over time the Xcode icon remains in the dock but sees less and less use.
Documentation plays a vital role in sustaining this approach. Comprehensive README files explain the available make targets, describe how to add new dependencies, and provide troubleshooting steps for common signing or simulator issues. Video walkthroughs and blog posts, including the detailed guide published by Scott Willsey, help others replicate the setup on their own machines. The collective knowledge grows as each contributor shares small improvements to the build scripts.
Ultimately the choice between Xcode and a command-line workflow reflects personal preference and project requirements. For many developers the speed, transparency, and flexibility of staying in the terminal outweigh the convenience of visual editors. They produce the same App Store binaries and ship the same features while enjoying a development experience that aligns more closely with the tools used in other languages and platforms. The ability to build complete Mac and iOS applications without ever launching Xcode demonstrates both the maturity of Apple’s command-line tools and the creativity of the community that continues to push them forward.
WebProNews is an iEntry Publication