I dug into this further and posting findings in case they help narrow down the regression. Environment: Reproduces on Xcode 27.0 (27A266a) and Xcode 27.1 RC (27A9275). Not present on Xcode 26.2. Binary/version diff: XCStringsParser.framework (Contents/SharedFrameworks/XCStringsParser.framework) jumped from CFBundleVersion 83.1.1 on Xcode 26.2 to 105 on Xcode 27 - not an incremental version bump. The binary itself also shrank (~4.48MB → ~2.56MB), and the linked SwiftSyntax/SwiftParser frameworks moved from 602.0.0 → 604.0.0. This looks like a rewrite of the parser between these releases, not a small patch. CPU profile of a live hang: I ran xcstringstool compile directly against one of our affected .xcstrings catalogs under Xcode 27.1 RC and sampled it mid-hang (sample <pid> 5). The catalog has a handful of keys whose localizations dict contains ~667 near-duplicate locale entries, versus the ~85-90 real supported locales the rest of the file uses (looks like upstream content-generation tooling emitting extra, unused region variants per key). The hot path is dominated by: icu::RegexMatcher::find / MatchAt (ICU regex matching) String.UTF16View._nativeCopy / _indexRange / _utf16Distance / _utf16Length (UTF-16 string-distance work) Swift generic-metadata lookups and NSArray bridging/copying This pattern (regex matching + O(n)-per-call string-distance work, repeated) looks consistent with a validation pass - likely format-specifier/placeholder detection, e.g. matching %1$@-style specifiers - being re-run per locale entry instead of cached per unique string value. A key with 667 duplicate-content locale entries would pay that cost ~667 times instead of ~85 (or once, if truly identical). That would explain why the slowdown specifically shows up on catalogs with this kind of locale-count bloat, rather than uniformly across all .xcstrings compiles.