A step-by-step guide to installing SwiftGen three different ways and creating your first swiftgen.yml configuration for a type-safe iOS project.
SwiftGen offers three common installation paths, and the right one depends on how much you value reproducibility across your team and CI. Homebrew is the fastest way to get a working binary on a single machine and is ideal for trying the tool out or for solo projects. Mint installs a specific pinned version from source and is the best choice when every developer and your CI must run the exact same SwiftGen version to avoid generated-code drift. The Swift Package Manager build tool plugin integrates SwiftGen directly into your Xcode or Package.swift build graph, so no one has to install a binary separately at all. Before picking, decide whether you want SwiftGen invoked manually, wired into a build phase, or run automatically by SPM. Teams that care about deterministic builds usually reject a bare Homebrew install because different machines can end up on different versions. Whichever route you choose, the outcome is the same: a swiftgen executable or plugin that can read a swiftgen.yml and emit Swift code. If you are unsure, a reasonable default is to start with Homebrew to evaluate the tool locally, then migrate to Mint or the SPM plugin once you decide to keep it, so your evaluation is fast but your long-term setup is reproducible.
If you have Homebrew installed, run brew install swiftgen in Terminal. Homebrew downloads SwiftGen and places the binary on your PATH, typically under /opt/homebrew/bin on Apple Silicon Macs or /usr/local/bin on Intel Macs. Verify the install by running swiftgen --version, which prints the installed version and confirms the binary is reachable. If the command is not found immediately after installing, your shell may not have the Homebrew bin directory on its PATH; open a new Terminal window or ensure your shell profile evaluates the Homebrew shellenv. Homebrew's convenience comes with a caveat for teams: brew upgrade can move you to a newer SwiftGen than your teammates are running, and mismatched versions can produce different generated output. For a shared codebase, treat a Homebrew install as a local convenience and pin the real version elsewhere, or move to Mint or the SPM plugin. For quickly evaluating SwiftGen on your own machine, though, Homebrew is the least-friction option and gets you generating code within a minute or two. If you later need a specific older version that the current formula no longer provides, that is precisely the situation where Mint's from-source pinning becomes the better tool, since Homebrew generally tracks the latest release.
Mint is a package manager for Swift command-line tools that installs and runs a specific version from source, which makes it excellent for pinning SwiftGen across a team. First install Mint itself, commonly with brew install mint. Then add SwiftGen to a Mintfile at your project root with a line like SwiftGen/[email protected], replacing x.y.z with the version you want to pin. Run mint bootstrap to install exactly the versions listed in the Mintfile. From then on, invoke SwiftGen through Mint with mint run swiftgen config run, which guarantees everyone uses the pinned version regardless of what is installed globally. Because the Mintfile is committed to your repository, a new contributor runs a single bootstrap command and is immediately aligned with the rest of the team and with CI. The trade-off is a slightly slower first run while Mint compiles the tool from source, and Mint itself becoming a dependency. For any project with more than one developer, this reproducibility is usually worth it and prevents the subtle bugs that version drift in generated code can introduce. Keep the pinned version explicit rather than floating, and treat a version bump as a deliberate change you review, since a new SwiftGen release can rename a template or adjust generated output in ways that ripple through your codebase.
SwiftGen provides a Swift Package Manager build tool plugin so you can run it as part of the build without installing a separate binary. Add the SwiftGen package to your project's package dependencies — in Xcode via File then Add Package Dependencies, or by adding it to the dependencies array in Package.swift — and then attach the plugin to the relevant target using the plugins parameter in your target definition, or in Xcode by selecting the target, opening Build Phases, and adding the SwiftGen plugin under Run Build Tool Plug-ins. With the plugin attached, SwiftGen runs automatically during the build and its generated files are produced into the build's derived output, which the compiler then picks up. This keeps everything inside SPM's dependency graph, so version resolution is handled by your Package.resolved and no teammate needs to brew or mint anything. The plugin approach is the most self-contained but is also the least flexible about where generated files land and requires your project to be structured for SPM plugins, so evaluate whether your build layout fits before committing to it. One practical consideration is that build tool plugins prompt for trust the first time they run in Xcode and can require configuration to run unattended in CI, so confirm your continuous integration accepts the plugin before you rely on it there.
SwiftGen is driven by a YAML configuration file, conventionally named swiftgen.yml and placed at your project root. At minimum it declares one or more parsers, each with inputs pointing at the resources to read and outputs describing the template and destination file. A simple config might have an xcassets parser with inputs listing your .xcassets folder, an outputs block specifying templateName: swift5 and an output file such as Generated/Assets.swift. You can set top-level input_dir and output_dir keys so individual paths stay short and relative. Create the file with your editor of choice and keep the indentation consistent, since YAML is whitespace-sensitive and a stray tab or misaligned key is the most common cause of a config that fails to parse. Start small with a single parser to confirm generation works before adding strings, fonts, or storyboards. The SwiftGen repository documents every parser and its available options, including the built-in template names for each, which is the authoritative reference when you extend the file beyond assets. Because SwiftGen resolves every input and output relative to the config file (or to input_dir and output_dir when set), the safest approach is to place swiftgen.yml at the repository root and express paths from there, which keeps the file portable across every machine that checks the project out.
With the tool installed and a config in place, run it once to confirm everything works. If you installed via Homebrew, run swiftgen config run from the directory containing your swiftgen.yml, or pass --config path/to/swiftgen.yml if it lives elsewhere. With Mint, use mint run swiftgen config run. With the SPM plugin, simply build the project and the plugin runs as part of the build. On success, SwiftGen writes the generated Swift files to the output paths you configured, and it prints a summary of what it generated. Open the generated file and confirm it contains the expected symbols — an Asset enum for a catalog, for example. If you are committing generated files, add the new files to your Xcode project and to source control; if you are generating at build time, add the output paths to .gitignore instead. A successful first run is the checkpoint that tells you the config is valid and the tool is correctly installed before you invest in automation. If the run fails, read the terminal output literally — it usually names the parser, template, or path at fault — and fix that one thing before rerunning, rather than changing several settings at once.
Once manual generation works, decide how SwiftGen will run going forward. The most common pattern is an Xcode build phase that regenerates code before compilation, so generated symbols are always current with your resources — worth setting up as a dedicated follow-up. Alongside that, settle your versioning strategy: a committed Mintfile or Package.resolved pins the exact SwiftGen version, and documenting the install and run commands in your project README saves new contributors from guesswork. Decide once whether generated files are committed or ignored, and apply that consistently to avoid confusing diffs. If you already use SwiftLint or SwiftFormat, add the generated files to their exclude lists so the tools do not fight over code SwiftGen owns. Finally, keep an eye on Xcode's native asset symbol and String Catalog features; if they already cover your images, colors, and localized strings, you may only need SwiftGen for fonts, storyboards, or custom parsers. Installing SwiftGen is quick — the durable value comes from wiring it in reproducibly and choosing a clear, documented workflow that the whole team follows. Treat the choice of install method, the pinned version, and the commit-versus-ignore decision as a single documented convention, because the failures that frustrate teams are almost always the result of different contributors making those choices differently on the same project.
Use Homebrew for a quick single-machine trial, Mint to pin an exact version across a team and CI, or the SPM plugin to run SwiftGen inside your build graph with no separate binary. Teams that need reproducible builds usually pick Mint or the plugin.
By convention it sits at your project root and is named swiftgen.yml. SwiftGen finds it automatically there, or you can point at another location with the --config flag.
Run swiftgen --version in Terminal. It should print the installed version. With Mint, run mint run swiftgen --version; with the SPM plugin, a successful build confirms it.
You need Xcode and the Apple toolchain to build and run your app. SwiftGen only generates Swift source from your resources; it does not compile or ship anything on its own.
Yes. Commit a Mintfile pinning the version, or rely on Package.resolved when using the SPM plugin. Avoid relying on a bare Homebrew install for shared projects since brew upgrade can cause version drift.
At least one parser with an inputs path to your resources and an outputs block specifying a templateName and an output file. Start with a single xcassets parser and expand from there.