Adopt Xcode String Catalog symbol generation across the app

[kyleve]

What

Switches the whole repo onto Xcode's built-in String Catalog symbol generation and makes every string reference type-safe. The hand-maintained string facades (Strings.swift ~1,730 lines, ShareStrings, WidgetStrings) and all raw String(localized: "key", bundle: .module) lookups are gone; user-facing copy now resolves through generated LocalizedStringResource symbols, so a typo'd or removed key is a compile error instead of a runtime surprise.

Scope is the codegen migration only — no new localization of currently-hardcoded/DEBUG surfaces or Info.plist strings.

How it works

• STRING_CATALOG_GENERATE_SYMBOLS = YES is set project-wide in Project.swift for the Tuist-native app/extension targets. The SwiftPM library targets generate symbols automatically from the toolchain (verified empirically), so they need no wiring.
• A manual catalog key some.key generates a .someKey symbol on LocalizedStringResource, referenced directly at call sites: Text(.tabPrimary), String(localized: .commonOk), Label(.evidenceAdd, systemImage:).
• Generated symbols are internal per target — fine here, because cross-module reuse already flows through public Swift API (e.g. the share extension renders kinds via WhereUI's public EvidenceKind.displayName), never raw keys.

Commits (one per module, bisectable)

1. Groundwork — enable the build setting; normalize the extension catalogs so every key is manual.
2. RegionKit — Region.localizedName switches over .regionCalifornia etc.
3. LifecycleKit — LifecycleFailureView uses .failureLaunchTitle / .failureLaunchRetry.
4. WhereCore — reminder/summary/issue-alert/backup strings; two fragile String(format:) compositions replaced with type-safe symbols (output unchanged).
5. WhereUI — delete the Strings facade; rewrite ~277 call sites across 30 files. Add WhereFormat for the cases that genuinely need logic (grouping-free years, plurals, enum switches, composed accessibility labels), each composing generated symbols internally. Add the 34 Evidence/common keys that previously only existed via defaultValue:. Replace StringsTests with WhereFormatTests.
6. WhereShareExtension / WhereWidgets — drop ShareStrings / WidgetStrings for the extensions' own generated symbols.
7. Docs — update the localization guidance (feature + module AGENTS/READMEs) to the "add a manual key → reference its symbol" workflow.

Verification

• ./swiftformat --lint . clean (326 files).
• Full Stuff-iOS-Tests scheme green (all bundles) on iPhone 17 / iOS 26.2.
• Catalog re-serialization verified lossless: 0 keys dropped, 0 existing values changed, 34 added.
• All composed/interpolated catalog values confirmed to match the old defaultValue: separators and argument order, and no catalog value contains markdown, so Text(String) → Text(.symbol) renders identically.

Reviewer notes

• The WhereUI catalog diff is large because the file was re-serialized into one fully-sorted, all-manual catalog — it's a re-sort + extractionState normalization, not content edits.
• Outside Text/Label/Button (verified to accept LocalizedStringResource), call sites use String(localized: .symbol) as a deliberate safety choice; a follow-up could tighten .navigationTitle(...) etc. to bare symbols.
• WhereFormat's enum-switch/compose helpers were cross-checked by hand against the old mappings; the untested cases are at parity with the previous StringsTests coverage.

  

[kyleve]

Posted by an AI agent on @kyleve's behalf.

CI is red due to an Xcode-toolchain gap, not a defect in this change — recommend holding until the runners have Xcode 27. Marking as draft.

Root cause

Xcode's built-in String Catalog symbol generation for SwiftPM package targets is unreliable on Xcode 26.x. Our RegionKit / LifecycleKit / WhereCore / WhereUI symbols generate fine in the app build graph, but the generated symbols file isn't reliably produced before the target's own sources compile in the test-bundle build graph — so CI fails with:

type 'String.LocalizationValue' has no member 'regionCalifornia'

Reproduced locally under Xcode 26.6 (Swift 6.3.3, = the macos-26 runner). Builds and passes the full Stuff-iOS-Tests scheme cleanly under Xcode 27 (Swift 6.4), where the SwiftPM change that wires catalogs into the Sources phase makes generation deterministic. GitHub's macos-26 image only ships Xcode 26.x — there is no Xcode 27 to pin to yet.

Fixes explored — all dead ends on 26.x

• Force the setting on the package targets — STRING_CATALOG_GENERATE_SYMBOLS is ignored for SwiftPM package targets (confirmed: =NO disabled a Tuist-native target but not a package target; CLI + XCODE_XCCONFIG_FILE overrides don't reach them). Can neither reliably enable nor disable it.
• Tuist XcodeProj integration (.external(name:)) — blocked by our single root-package layout: tuist generate crashes with a duplicate-path error, the root package's products aren't exposed as .external, and SwiftPM won't let a subdirectory manifest reference sources via ../ (would require relocating all module sources).
• Commit a generated-symbols shim (the clever idea we tried) — Xcode 26.x's built-in generation for packages is unconditional, so a committed shim collides → invalid redeclaration. This duplicate-symbols wall is documented independently: https://elegantchaos.com/2026/02/12/string-catalogues.html

Corroboration that this area is buggy / actively patched on 26.x

• Apple-confirmed SPM string-symbol compile bug, fixed only in a later 26.x beta: https://developer.apple.com/forums/thread/824485
• SwiftPM mechanism (catalogs as Sources): Support String Catalog symbol generation by adding String Catalogs as both Sources and Resources swiftlang/swift-package-manager#8815

Recommendation

The branch is correct and needs zero changes — it's green on Xcode 27. Hold as draft until the CI runners have Xcode 27, at which point this should pass as-is. If we need type-safe strings sooner, the only 26.x-viable path is a custom SwiftPM build-tool-plugin codegen (gated to not run under Xcode) — more moving parts; happy to spike it separately if desired.