Swift package
Configurable code generation for swift-package-resources
package-resources-cli is the default generator for swift-package-resources. The important API is its .packageresources manifest: it makes output location, visibility, naming, grouping, and enabled resource types repeatable across machines and CI.
version: "4.0"
output: Sources/DesignSystem/Resources.generated.swift
access-level: package
group-by-catalog: true
colors:
group-by-folders: true
split-by-key-path: true
images:
group-by-folders: true
fonts:
ignore: false
nibs:
ignore: true
xcstrings:
split-by-key-path: true
acronyms:
values: [id, ID, URL, API]
Top-level values are defaults. Each resource section can inherit them, override one behavior, use the default alias, or opt out with ignore: true. Package-level defaults can be combined with target-specific manifests so a design-system target exposes shared resources while features keep local catalogs local.
swift package resources config init --format yaml
swift package resources generate
Use config edit for scripted migrations instead of rewriting YAML by hand:
swift package resources config edit \
--indentor "\s" \
--indent-size 2
The generator supports colors, images, fonts, SceneKit scenes, string catalogs, nibs, and storyboards. In v4 every resource type starts enabled; disable only the types a target does not own.
| Configuration | Controls |
|---|---|
output / access-level | Generated file location and declaration visibility |
group-by-catalog | Whether catalogs create namespaces |
group-by-folders | Whether resource folders become nested groups |
split-by-key-path | Whether hierarchical names become Swift key paths |
acronyms.values | Stable identifier casing for project vocabulary |
ignore | Per-resource opt-out from v4’s enabled-by-default behavior |
Top-level policy is inherited by each resource kind, while target-local manifests can override only what differs. That keeps code generation deterministic without forcing every target into one namespace or visibility scheme.