SweetPad: building and testing Apple apps from the terminal

Why SweetPad targets terminal-first Apple development

SweetPad addresses a recurring mismatch in Apple development. The standard build machinery is available through `xcodebuild`, but routine tasks such as selecting a scheme, choosing a simulator, rebuilding after a change, and collecting test results can require long command lines and verbose output. The README describes SweetPad as "xcodebuild for humans and agents," which identifies both its intended users and its design goal. Human developers can use the guided interface, while agents can use structured output and exit codes.

The project supports iOS, macOS, tvOS, watchOS, and visionOS applications. Its documented project inputs include Xcode projects and workspaces, Tuist, XcodeGen, and Swift packages. That range is useful for repositories that contain more than one project definition or generate their Xcode configuration. SweetPad does not present itself as a replacement for Tuist, XcodeGen, or Xcode projects. It provides a command-line interface for working with them.

The distinction is important. The repository is primarily written in Rust, but the documented application workflows remain tied to Apple targets and Xcode-oriented development. The VS Code extension is optional, and the README states that the CLI does not depend on it. A team can therefore use SweetPad from a terminal, an editor, or an automation process without requiring the extension for every workflow.

How SweetPad run builds and relaunches an application

The clearest documented workflow is `sweetpad run`. On the first use, SweetPad asks for a scheme and a destination, then saves those answers for later commands. The active command builds the application, installs it on the selected destination, launches it, and streams logs. While the session is active, the README documents `r` for a rebuild and `q` to quit.

Destinations are selected with `--on`. The README shows a simulator named `iPhone 16 Pro`, while connected devices and the Mac are also listed as supported destination types. A separate testing example uses `sweetpad test --on booted` to run tests on an already running simulator. This keeps destination selection out of the main command when a developer wants to target a known environment.

The feature list also documents `sweetpad run --hot` for applying saved Swift changes without restarting the application. The README does not specify which changes are eligible for this mode, so developers should not assume that every source edit is equivalent to a normal launch. A project with startup migrations, one-time initialization, or major architectural changes may need a full rebuild or restart even when hot reload is available.

The repository layout shows Rust crates named `sweetpad-cli`, `sweetpad-core`, `sweetpad-lib`, and a native workspace member used by the VS Code extension. The CLI dependency list includes `clap` for command definitions and `dialoguer` for terminal selection. Based on those files, command parsing, prompts, configuration, and the terminal workflow are implemented in Rust, while editor integration is kept separate from the standalone CLI.

Installing SweetPad and completing a first simulator run

The README uses a dedicated Homebrew tap for installation. After installation, the developer enters an application directory containing a supported project and starts the run workflow. The README does not list manual installation variants or a complete Xcode compatibility matrix, so the documented path is the clearest starting point for a new installation.

Install the CLI:

brew install sweetpad-dev/tap/sweetpad

The command should install the `sweetpad` executable through Homebrew. No VS Code extension installation is required for this workflow.

Enter the application directory and start the interactive build-and-run process:

cd MyApp
sweetpad run

If a scheme or destination has not been saved, SweetPad should prompt for those values. The command then builds, installs, launches, and streams logs. The active session exposes these keyboard controls:

r
q

Press `r` to request a rebuild. Press `q` to leave the run session.

To choose a named simulator or device explicitly, the README gives this command:

sweetpad run --on "iPhone 16 Pro"

The name must match an available destination. The README also documents `sweetpad test --on booted` for testing against a simulator that is already running:

sweetpad test --on booted

This workflow demonstrates installation, destination selection, launching, and testing. It does not establish requirements for a particular Xcode version, and the README does not document how to reset saved scheme or destination choices.

Testing and automation features in the SweetPad CLI

SweetPad's testing documentation covers more than running the complete test suite. The README lists single-test execution, rerunning failures, retrying flaky tests, and exporting coverage and JUnit reports. The exact command syntax for selecting one test or configuring retries is not included in the README, so those options should be taken from the linked SweetPad documentation before being placed into a script.

For CI, the feature list says that every command supports JSON output and specific exit codes. This is the most relevant capability for agents and shell automation because it avoids treating human-readable build output as the only machine interface. However, the README does not show the JSON schema or enumerate the exit codes. An integration should inspect command help and the linked scripts and CI documentation instead of assuming a shape.

The CLI also has editor-oriented workflows. `sweetpad bsp init` sets up SourceKit-LSP for Neovim, Zed, Helix, and Emacs. The README lists breakpoints in Neovim, Zed, or VS Code through `sweetpad dap`, scripted `lldb` sessions, and structured crash reports. These features support a broader terminal and editor workflow, but they are separate from the basic `sweetpad run` path.

The repository includes a `skills/` directory and links to documentation for agent skills. The stated purpose is to teach coding agents how to use the CLI. The README does not identify supported agent products or document installation and discovery of those skills, so agent integration should be verified directly in the repository and documentation before adoption.

SweetPad versus direct xcodebuild automation

SweetPad is the better fit when the main problem is command ergonomics around an existing Xcode-oriented project. It turns scheme and destination selection into guided prompts, keeps common commands short, streams application logs during a run, and offers an interactive rebuild loop. It also connects testing, hot reload, editor debugging, JSON output, and exit-code handling into one CLI surface.

A direct `xcodebuild` script remains the more transparent alternative when control over every raw argument matters. CI systems that already encode project-specific settings, unusual destinations, or undocumented Xcode behavior can keep that logic visible. SweetPad adds an abstraction layer between the developer and Xcode, which improves common workflows but means that unusual project behavior must be validated through SweetPad itself.

The saved first-run choices are another practical distinction. A direct script can derive all parameters from files or command-line values. SweetPad's documented behavior is to ask once and save the scheme and destination. The README does not document a reset command, configuration path, or CI-specific configuration mechanism. A build server should therefore establish whether prompts and local state are acceptable before using the same flow as a developer workstation.

Hot reload and interactive controls also fit development sessions more closely than unattended automation. The README does not say that `sweetpad run --hot` works with every Swift change or that interactive keys can be used in a noninteractive job. Direct `xcodebuild` remains easier to reason about when a job needs deterministic, fully visible command construction.

Maintenance, releases, Rust requirements, and licensing

The repository is not archived, and its last push was on 2026-10-14. Recent releases include `v0.2.19` on 2026-10-10, `cli-v0.1.13` on 2026-10-10, and `cli-v0.1.12` on 2026-10-04. These dates indicate recent repository activity, but the different version schemes matter when selecting a release. The main project tag and the CLI-specific tags should not be treated as interchangeable without checking the release contents.

The root `Cargo.toml` declares workspace version `0.1.13`, edition 2024, and `rust-version = "1.94"`. The workspace contains the CLI, core library, shared library, and native VS Code workspace member. The README's Homebrew command is the documented installation path for users. It does not explain whether source contributors need to run a separate Cargo build or which exact Swift and Xcode versions the CLI supports.

The license metadata is inconsistent within the repository. The README labels SweetPad as MIT and links to `LICENSE.md`, while the root `Cargo.toml` declares `license = "MIT OR Apache-2.0"`. This is a documentation and packaging issue that should be checked before redistributing binaries or incorporating the code into another project. The README does not provide a separate license grant for the VS Code extension or its native workspace member, so those files should be reviewed directly.

The README does not document an upgrade policy, compatibility matrix, configuration migration process, or rollback procedure. In particular, it does not say whether saved scheme and destination choices survive CLI upgrades. Because the project has both main and CLI release tags, an adopter should record which tag was installed and review the corresponding release notes before upgrading.

Editorial conclusion

SweetPad fits developers and coding agents that repeatedly build, run, and test Apple apps from a terminal, particularly when guided selection and structured output matter. It is less suitable for a workflow that must operate independently of Apple's Xcode tooling. Before adoption, verify the required Xcode environment, confirm that the project's schemes and destinations are detected correctly, and inspect the license files because the README identifies MIT while the root Cargo.toml declares `MIT OR Apache-2.0`.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sweetpad-dev/sweetpad on GitHub