Configure SwiftGen to turn your asset catalog images and named colors into compile-checked Swift accessors, then use them cleanly in UIKit and SwiftUI.
Asset catalogs store images and named colors, and by default you access them with strings: UIImage(named: 'iconSettings') or UIColor(named: 'BrandPrimary'). Those strings are invisible to the compiler, so a typo, a renamed asset, or a deleted image produces no warning — it fails at runtime as a missing image or a fallback color, often noticed only when a user or a QA pass finds it. SwiftGen's xcassets parser reads your catalog and generates an Asset enum whose cases correspond to every image and color set. You then write Asset.iconSettings.image or Asset.brandPrimary.color, and the compiler guarantees the symbol exists. Rename an asset, regenerate, and every stale call site becomes a compile error you can fix immediately. Autocomplete also becomes genuinely useful because Xcode can list every asset by name. This is SwiftGen's most popular use case and the clearest demonstration of its value: it converts a whole class of silent runtime failures into loud, immediate compile-time errors, which is exactly the trade you want when shipping a real app. It is worth noting that recent Xcode versions offer native asset symbol generation that achieves the same compile-time safety for images and colors without any extra tool, so weigh whether you need SwiftGen here specifically or mainly for its other parsers.
To generate asset accessors, add an xcassets section to your swiftgen.yml. Under it, list your catalog under inputs — for example Resources/Assets.xcassets — and define an outputs block. The outputs block needs a templateName and an output file path. For a modern project, templateName: swift5 produces an Asset enum with nested namespaces mirroring your catalog folder structure. Set the output to a dedicated file such as Generated/Assets.swift so it is easy to find and to exclude from linters. If your assets span multiple catalogs, list each under inputs and SwiftGen merges them. You can also pass template parameters under a params key — for instance to change the enum name, set the access level to public for a shared framework target, or select whether output targets UIKit or SwiftUI types. Keep the YAML indentation consistent, because the xcassets, inputs, and outputs keys must nest correctly for the parser to run. Once saved, this single parser block is all SwiftGen needs to turn your entire catalog into typed Swift on the next run. Because paths resolve relative to the config file (or to input_dir if you set it), double-check that the inputs path points at the real .xcassets bundle from where swiftgen.yml lives, as a path that merely looks right is the most frequent reason a first run generates nothing.
Run the tool with swiftgen config run, mint run swiftgen config run if you pinned it with Mint, or simply build if you use the SPM plugin. SwiftGen reads the catalog, applies the template, and writes your Generated/Assets.swift. Open that file and inspect it: you will see an enum, commonly named Asset, containing static members for each image and color, and often nested enums for asset folders so a folder named Icons becomes Asset.Icons. Each image member exposes an image property returning a UIImage (or an Image for SwiftUI templates), and each color member exposes a color property returning a UIColor or SwiftUI Color. Reading the generated file is worthwhile the first time because it shows you exactly what names SwiftGen derived from your asset names — it converts identifiers into safe Swift symbols, so an asset named brand-primary becomes brandPrimary. If a name looks wrong, adjust the asset name in the catalog or the template's naming option and regenerate. Confirm the file compiles by building once before you start using the symbols across your codebase. If two differently named assets sanitize to the same Swift identifier, SwiftGen will surface a collision, which is a signal to rename one asset so every generated symbol stays unambiguous.
With the file generated and added to your target, replace stringly-typed lookups throughout your UIKit code. Where you previously wrote imageView.image = UIImage(named: 'iconSettings'), you now write imageView.image = Asset.iconSettings.image. For colors, view.backgroundColor = Asset.brandPrimary.color replaces UIColor(named: 'BrandPrimary'). Because these are real Swift symbols, command-clicking one jumps to its definition, and renaming the asset plus regenerating surfaces every call site that needs updating as a compile error. The generated image property returns a non-optional UIImage in the standard templates, which removes the awkward optional handling that UIImage(named:) forces on you and makes call sites cleaner. If you organize assets into folders, the nested namespaces keep related symbols grouped, so Asset.Onboarding.welcomeHero reads clearly. Migrate incrementally: you do not have to convert everything at once, since the generated accessors coexist with any remaining string-based lookups. Convert a screen at a time, build after each, and you steadily eliminate an entire category of silent asset bugs from the codebase without a risky big-bang refactor. A useful side benefit of the non-optional return is that reviewers stop seeing force-unwraps and nil-coalescing scattered around image lookups, which quietly improves the safety of the surrounding code as you migrate.
SwiftGen can emit SwiftUI-friendly output so the generated members return SwiftUI's Image and Color types directly. Choose the appropriate template — the modern templates support SwiftUI output, sometimes via a template parameter — and regenerate. In your views you then reference the generated members, for example .foregroundStyle(Asset.brandPrimary.swiftUIColor) or an Image initializer that takes the generated asset, depending on the template you selected. The exact member names depend on the template, so check the generated file to see whether SwiftUI accessors are named color, swiftUIColor, image, or swiftUIImage. Using generated symbols in SwiftUI gives the same compile-time safety as UIKit and pairs well with a design-system approach where named colors live in the catalog and every view references them by symbol. Be aware that recent Xcode versions natively generate SwiftUI symbols for asset colors and images too, so for a new SwiftUI-only app you may already have Color(.brandPrimary)-style access without SwiftGen. Decide based on whether you need SwiftGen's other parsers or custom output before adding it solely for SwiftUI assets. If your app mixes UIKit and SwiftUI, one advantage of a SwiftGen template is that it can emit both UIKit and SwiftUI accessors from the same catalog, giving every layer of the app a consistent, symbol-based way to reach the same named color or image.
Type-safe accessors are only reliable if they regenerate whenever assets change. If you commit the generated file, you must remember to rerun SwiftGen after adding or renaming an asset, or the symbols go stale and either fail to compile or reference the wrong resource. The robust solution is to run SwiftGen automatically — as an Xcode build phase that runs before compilation, or through the SPM plugin — so the generated file always reflects the current catalog. Add the generated file to your linters' and formatters' exclude lists, since it is machine-written and should not be reformatted or flagged. If you use a build phase, configure its input and output file lists so Xcode can skip regeneration when nothing changed, which keeps incremental builds fast. Whatever you choose, document it so a new contributor who adds an image knows how the corresponding symbol appears. Treating the generated file as a build output rather than hand-maintained source is the mindset that keeps type-safe assets trustworthy over the life of the project. When you add a second parser later, remember to extend those input and output file lists too, because an incomplete list is the classic reason a newly added resource fails to trigger regeneration.
If generation produces no symbols, the most common cause is an inputs path that does not point at the actual .xcassets folder; paths are resolved relative to the config or to your input_dir, so double-check them. If the tool runs but Xcode cannot find the Asset type, confirm the generated file is added to your app target's membership, not just present on disk. If an asset name generates an unexpected Swift symbol, remember SwiftGen sanitizes names into valid identifiers, so hyphens and spaces are transformed; rename the asset for a cleaner symbol if needed. A wrong or missing templateName causes a template-resolution error — the built-in names are documented, and a typo there stops generation entirely. Finally, if colors return unexpectedly, make sure the color is defined as a named color set in the catalog rather than only in code. When in doubt, run generation from the terminal directly to see SwiftGen's full output and error messages, which are far more informative than a silent build phase and pinpoint exactly which parser or path is misconfigured. If everything looks correct but symbols still do not update, clean the build folder to rule out Xcode caching before assuming the config is at fault, since a correct on-disk file can occasionally be masked by stale derived data.
The xcassets parser produces an enum (commonly Asset) with members for each image and color, exposing an image property (UIImage or SwiftUI Image) and a color property (UIColor or SwiftUI Color), with nested namespaces mirroring your catalog folders.
Instead of UIImage(named: 'icon'), write Asset.icon.image. The property is non-optional in the standard templates, which removes the optional handling that UIImage(named:) requires.
Yes. Select a SwiftUI-capable template or template parameter and the generated members return SwiftUI Image and Color. Check the generated file for the exact accessor names your template produced.
SwiftGen sanitizes asset names into valid Swift identifiers, so hyphens, spaces, and other characters are transformed into camelCase. Rename the asset in the catalog if you want a cleaner generated symbol.
Not necessarily for images and colors alone. Recent Xcode generates native asset symbols, so SwiftGen's asset value is strongest when you also need fonts, strings, storyboards, or custom template output.
Run SwiftGen automatically via an Xcode build phase or the SPM plugin so it regenerates whenever the catalog changes, and exclude the generated file from linters and formatters.