The swiftgen command not found error is almost always a PATH or install issue. Here are the real causes and concrete fixes, in order of likelihood, including the Apple Silicon path trap.
The error swiftgen: command not found means the shell — whether your interactive Terminal or the shell Xcode uses to run a build phase — cannot find an executable named swiftgen on its PATH. It does not mean SwiftGen is broken or that your config is wrong; it means the binary is either not installed or not reachable from where you are running it. This distinction matters because the fix differs depending on context. If you see it in Terminal, the tool likely is not installed or your shell profile does not include the install directory. If you see it only inside an Xcode Run Script build phase while Terminal works fine, the tool is installed but Xcode's minimal build environment does not have the right directory on PATH. Read the error's context carefully: note whether it happened in Terminal or in the Xcode report navigator, and which install method you used. Almost every case resolves to one of a small number of causes covered below, ordered from most to least common so you can work through them quickly. The single most valuable habit is to reproduce the failure in the exact context where it appears, because a fix that works in Terminal does nothing for a build phase that runs in a different environment entirely.
The simplest cause is that SwiftGen was never installed on this machine, or an install failed partway. Confirm by running swiftgen --version in Terminal. If that also reports command not found, install it: brew install swiftgen for a Homebrew install, or set up Mint and run mint bootstrap against a Mintfile that pins SwiftGen. On a new CI machine or a teammate's fresh checkout, this is the usual explanation — the project expects SwiftGen but nothing installed it. If you use the Swift Package Manager plugin, there is no separate binary to install, so a command-not-found error means you are trying to invoke a binary that your workflow does not actually provide; in that case run generation through the plugin by building, not by calling swiftgen directly. After installing, run swiftgen --version again to confirm the binary now resolves. If it installs but still is not found, the problem has shifted from installation to PATH, which the next cause addresses. Always verify the install succeeded before assuming a deeper configuration problem exists. It is also worth confirming the install actually completed rather than erroring midway, since a partially failed brew or mint step can leave you believing the tool is present when it never finished installing.
If swiftgen --version works in one Terminal but not another, or fails inside scripts, the binary exists but its directory is not on the PATH being used. Homebrew installs to /opt/homebrew/bin on Apple Silicon Macs and /usr/local/bin on Intel Macs. Your interactive shell picks this up if your profile evaluates the Homebrew shellenv, but a non-login or non-interactive shell may not. Find where the binary lives with which swiftgen or by checking both Homebrew bin directories. Then ensure that directory is on PATH for the context that fails — add it to your shell profile for Terminal, or export it inside a script. Do not move the binary or create symlinks in system directories as a workaround; fixing PATH is cleaner and survives upgrades. For Mint-based setups, the same applies to the mint binary and to Mint's linked tools directory. Once the correct directory is on PATH, the command resolves. If Terminal is fine but only Xcode fails, the issue is specifically the build environment's PATH, covered next. Remember that changes to your shell profile only affect newly opened shells, so open a fresh Terminal window after editing the profile rather than expecting the current session to pick up the change.
The most common place this error appears is inside an Xcode Run Script build phase, even when Terminal works perfectly. Xcode runs build phases with a minimal environment that does not source your shell profile, so Homebrew and Mint directories are absent from PATH. Compounding this, Apple Silicon and Intel Macs use different Homebrew locations, so a script that hardcodes /usr/local/bin fails on an M-series Mac and vice versa. The reliable fix is to invoke the binary by absolute path with a fallback: check for /opt/homebrew/bin/swiftgen first, and if it is absent, use /usr/local/bin/swiftgen. Alternatively, export a PATH at the top of the script that includes both directories before calling swiftgen. For Mint, apply the same fallback logic to the mint executable. After editing the script, build and read the Xcode report navigator to confirm the phase now finds the tool. If your team mixes Apple Silicon and Intel hardware, this dual-path approach — or switching to the SPM plugin, which locates the tool itself — is essential to keep the build working for everyone. A script that assumes a single architecture is a time bomb the day a teammate on different hardware checks the project out, so write the fallback even if every machine you own today happens to be Apple Silicon.
Sometimes the binary is installed and on PATH, but you are calling it the wrong way for how it was installed. If you pinned SwiftGen with Mint, there may be no global swiftgen on PATH at all — you must invoke it as mint run swiftgen config run, so a bare swiftgen call fails as expected. Conversely, if you installed via Homebrew, mint run swiftgen will not help if Mint is not set up. If you adopted the SPM build tool plugin, there is no standalone command to run; generation happens during the build, and calling swiftgen from a script is simply the wrong model. Check your project's documented workflow and your swiftgen.yml setup to confirm which invocation is correct. Mixing methods — for instance a Run Script phase that calls a bare swiftgen while the team standardized on Mint — is a frequent source of this error on some machines but not others. Align the invocation in your build phase with the install method the project actually uses, and the command resolves consistently everywhere. This is exactly why teams that document one install method and one invocation in the README see far fewer of these machine-specific failures than teams where each contributor installed the tool however they preferred.
This error frequently appears on continuous integration or when a new contributor first builds the project, because those environments start without any local tools. CI runners are typically clean, so unless your pipeline explicitly installs SwiftGen — via a Homebrew step, a Mint bootstrap, or by resolving the SPM plugin — the build phase will fail with command not found. The fix is to make installation part of the environment setup rather than assuming it is present. Add a step that runs brew install swiftgen or mint bootstrap before the build, or rely on the SPM plugin so SPM resolves the tool during dependency resolution. Pin the version so CI matches local machines and generated output is deterministic. For new contributors, a documented setup command in the README prevents the confusion of a project that will not build on first checkout. The underlying principle is that SwiftGen is an external dependency of your build, and like any dependency it must be provisioned in every environment that builds the app, not just on the original author's machine. Caching Mint's or Homebrew's install directory between CI runs is a common optimization that keeps the provisioning step from slowing every build while still guaranteeing the tool is present.
After applying a fix, verify it in the exact context that failed. If Terminal was the problem, run swiftgen --version in a new Terminal window to confirm PATH changes took effect. If the build phase failed, do a clean build and read the phase output in the Xcode report navigator to confirm SwiftGen ran. To prevent the error from recurring, standardize on one install method across your team and CI and document it, use absolute paths with a Homebrew fallback in any build script, and pin the version so environments stay aligned. Consider adding a friendly guard to your build script that prints an actionable message — telling the developer exactly which command to run to install SwiftGen — if the binary is missing, rather than a cryptic failure. If you would rather avoid the entire class of PATH problems, migrating to the SPM build tool plugin removes the need to locate a binary at all. A little upfront standardization turns a recurring, machine-specific annoyance into a solved problem that new contributors never hit. Treat the first occurrence as a prompt to fix the setup for everyone, not just to unblock your own machine, and the error stops coming back.
Xcode runs build phases with a minimal PATH that does not include Homebrew or Mint directories. Reference the binary by absolute path with a fallback between /opt/homebrew/bin and /usr/local/bin, or export a PATH that includes both.
On Apple Silicon Macs, Homebrew installs to /opt/homebrew/bin, so the binary is at /opt/homebrew/bin/swiftgen. On Intel Macs it is /usr/local/bin/swiftgen. Scripts should check both.
Run swiftgen --version in Terminal. If it prints a version, it is installed and on PATH. If it reports command not found, install it via Homebrew or set up Mint and run mint bootstrap.
A Mint-pinned tool may not be on the global PATH. Invoke it as mint run swiftgen config run instead of calling swiftgen directly, and make sure your build phase uses the same form.
CI runners start clean. Add an explicit install step (brew install swiftgen or mint bootstrap) before the build, or use the SPM plugin so the tool is resolved during dependency resolution.
Use the Swift Package Manager build tool plugin. It runs during the build and locates the tool itself, so there is no binary to find on PATH and no Apple Silicon path trap.