# SwiftGen: type-safe Swift constants for assets, strings and storyboards

> SwiftGen generates Swift source from your resource files so asset names, localised strings and storyboard identifiers compile instead of crashing. Here is how it installs, how the config file drives it, and where it stops being worth the setup.

**SwiftGen/SwiftGen** — The Swift code generator for your assets, storyboards, Localizable.strings, … — Get rid of all String-based APIs!

- Repository: https://github.com/SwiftGen/SwiftGen
- Stars: 9,549 · Forks: 764
- Language: Swift
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/swiftgen-swiftgen

## The string-literal problem SwiftGen removes from iOS code

Every iOS project eventually contains a line like a UIImage lookup or a localisation key written as a bare string. The compiler cannot check any of it. Rename an asset in the catalog, delete a key from Localizable.strings, or mistype a storyboard identifier, and nothing fails until that code path runs on a device. SwiftGen exists to move that class of mistake from runtime to compile time. It reads your resource files and emits Swift source containing constants, so the resource name is a symbol the compiler resolves. The README lists the benefit directly: avoiding the risk of a typo, free auto-completion, and avoiding the risk of using a non-existing asset name. The audience is Swift and iOS teams with a meaningful number of assets, localised strings, fonts or Interface Builder files, and enough build automation that adding a generation step is not a burden. A small app with five images does not need it.

## How SwiftGen turns resource files into Swift source

SwiftGen is a command line tool, not a runtime library. It parses resource files, feeds them into a template, and writes Swift source to disk. The repository splits this across Sources/ and SwiftGenKit.podspec, with a Rakefile and rakelib/ driving the build. Parsers cover the resource types listed in the README: asset catalogs, colors, Core Data, files, fonts, Interface Builder files, JSON and YAML, plists, and Localizable strings. The output shape is controlled by Stencil templates, and the README notes that predefined templates ship with the tool while custom ones can generate whatever fits your guidelines. The configuration file is the centre of the workflow: it names which parser runs against which input paths, which template is used, and where the generated file goes. That means the generated code is a build artefact you own. It should be committed to version control or produced by a script build phase, and the README's ZIP instructions make the same argument for the binary itself, recommending that you unarchive it inside your project directory and commit its content so all coworkers use the same version.

## Installing SwiftGen and running a first generation

The README offers five install paths: a release ZIP, CocoaPods, Homebrew, Mint, and compiling from source. Homebrew is the shortest for a single machine. It installs system-wide, and the README warns that you should make sure all your coworkers have the same version installed, because the version is no longer pinned by the project.

```bash
$ brew update
$ brew install swiftgen
```

If you would rather pin the version per project, Mint installs a specific repository revision. SwiftGen 6.0 or higher is required for this path.

```bash
$ mint install SwiftGen/SwiftGen
```

The CocoaPods route is the one the README calls a trick: SwiftGen is not a library your code links against, so adding the pod puts the binaries in Pods/SwiftGen/bin/swiftgen without adding Swift files to the Pods group. That still gives you a pinned version per project.

```ruby
pod 'SwiftGen', '~> 6.0'
```

After running pod install --repo-update, the README shows invoking the binary from a Script Build Phase with a guard so a missing install produces a warning instead of a broken build.

```bash
if [[ -f "${PODS_ROOT}/SwiftGen/bin/swiftgen" ]]; then
  "${PODS_ROOT}/SwiftGen/bin/swiftgen" …
else
  echo "warning: SwiftGen is not installed. Run 'pod install --repo-update' to install it."
fi
```

If you unzip the release instead, the README invokes it as "${PROJECT_DIR}/swiftgen/bin/swiftgen". The command arguments themselves are not reproduced in the README section available here, so read the configuration file documentation before writing your first invocation. One known issue is documented: on macOS before 10.14.4, SwiftGen 6.2.1 and later can fail with a dyld Symbol not found error, which the README says requires installing the Swift 5 Runtime Support for Command Line Tools.

## Where SwiftGen stops paying for itself

The tool has no runtime component, which is a strength, but it also means nothing enforces that the generated file is current. If a developer adds an asset and forgets to regenerate, the build succeeds and the constant is simply missing. The failure mode is a confusing compile error or a silently absent symbol, not a clear message that the resources changed. The README does not document a watch mode or an automatic regeneration on file change, so freshness depends entirely on your build phase or CI step. Second, the generated code is committed or produced, and either choice has a cost: committing means merge conflicts in a large generated file, and not committing means every checkout and CI machine needs the tool installed at a matching version. Third, the template layer is a real dependency. Custom Stencil templates are the reason SwiftGen fits unusual codebases, but they are also code you maintain, and a template that drifts from your project's conventions produces output nobody wants to review. Finally, if your project has already moved to Apple's String Catalogs, check whether the parser and template you need exist before assuming the Localizable.strings workflow maps across; the README section available here documents the strings parser, not a String Catalog parser.

## SwiftGen compared with R.swift

R.swift is the other well-known tool in this space, and the difference is architectural rather than cosmetic. R.swift is built around a specific Swift API surface that it generates for you, so the shape of the output is largely decided by the tool. SwiftGen separates parsing from emission through Stencil templates, so the same parsed resource data can be rendered into whatever naming scheme, access level or file layout your project uses. That flexibility is the reason SwiftGen appears in codebases with strict style guides, and it is also the reason a SwiftGen setup can take longer to configure than an R.swift one: you are choosing a template, not accepting a fixed API. If you want the fastest path to typed resources and you are happy with someone else's naming conventions, the fixed-output approach is less work. If you need generated code that matches existing conventions, or you want to emit something other than Swift constants from the same resource data, the template layer is the reason to pick SwiftGen.

## Maintenance, licensing and what a version bump costs

SwiftGen is MIT licensed, which permits commercial and closed-source use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement and it does not impose copyleft obligations on your app. This is not legal advice; read the LICENCE file in the repository if the distinction matters to your organisation. On maintenance, the last push to the repository was on 2026-04-16, so the project is not abandoned, but the release history is worth reading carefully: 6.6.3 shipped on 2024-03-02, and before that 6.6.2 on 2022-08-13. Release cadence is therefore slow and uneven, which matters less than it sounds because the tool runs at build time and has no runtime footprint in the shipped app. Upgrading is mostly a matter of re-running generation and reviewing the diff: if the template output changed between versions, the diff will be large but mechanical. The real upgrade cost sits in the install path you chose. Homebrew and Mint give you a version to bump in one place; the committed ZIP means replacing a directory in the repository; CocoaPods means a Podfile constraint. Pick the one your CI can reproduce before you pick anything else.

## Conclusion

Adopt SwiftGen if your app reads resources through string literals and you already run a build phase or CI step that can regenerate code. Do not adopt it if your team cannot commit to regenerating on every resource change, because a stale generated file is worse than no generated file. Before rolling it out, verify three things: that your chosen install path (Homebrew, Mint, CocoaPods or the release ZIP) pins a version your whole team shares, that the templates you pick cover the resource types you actually use, and that the generated output is committed or regenerated in CI. Start from a single parser entry in swiftgen.yml rather than converting every resource type at once.

## FAQ

### How do I install SwiftGen?

The README lists five options: downloading the release ZIP and committing it into your project, CocoaPods via pod 'SwiftGen', Homebrew with brew install swiftgen, Mint with mint install SwiftGen/SwiftGen, or compiling from source with rake cli:install. Homebrew and Mint install system-wide, while the ZIP and CocoaPods pin a version per project.

### How do I use SwiftGen?

You run the swiftgen binary as a build step, and a configuration file tells it which parser to run against which resource files, which Stencil template to use, and where to write the generated Swift source. The README recommends invoking the binary from a Script Build Phase so the generated constants stay in step with your resources.

### What is SwiftGen?

SwiftGen is a command line tool that generates Swift code for a project's resources, such as images, localised strings, colors, fonts and Interface Builder files, so they are type-safe to use. The README states that it avoids typo risk and non-existing asset names, with the compiler catching mistakes instead of the app crashing at runtime.

### How does SwiftGen compare with R.swift?

Both generate typed Swift access to resources, but SwiftGen separates resource parsing from code emission through Stencil templates, so you can shape the generated API yourself, while R.swift is built around a specific generated API surface. The trade-off is configuration effort: SwiftGen asks you to choose or write a template.

## Sources

- [Issues](https://github.com/SwiftGen/SwiftGen/issues)
- [License: MIT](https://github.com/SwiftGen/SwiftGen/blob/stable/LICENSE)
- [README](https://github.com/SwiftGen/SwiftGen/blob/stable/README.md)
- [Releases](https://github.com/SwiftGen/SwiftGen/releases)
- [SwiftGen/SwiftGen on GitHub](https://github.com/SwiftGen/SwiftGen)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/swiftgen-swiftgen