xcstringstool compile (and by extension CompileXCStrings in Xcode/Bazel builds) hangs indefinitely on .xcstrings files where one or more keys have a localizations entry count that is a significant outlier relative to the rest of the file's keys — even when total file size and total entry count are unremarkable. The tool produces no error, warning, exception, or log output; it simply spins at high CPU with flat memory until killed.
xcstringstool compile hangs/spins indefinitely when a .xcstrings file contains a key with a locale count far exceeding the file's other keys
My FB24882338 request is here, which has a reproducible strings file attached.
Seeing the issue on 27.1 beta as well as GM Xcode Version: 27.0 (Build 27A266a), this is a regression from Xcode 26.x.
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.
@desaikpalpays Thanks for filing the bug, did someone asked you to file it? I see the sysdiagnose so hope will see the hang files attached, have you tried with the latest beta as the bug is from Sep 21st?
You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identified fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.
For more details on when you'll see updates to your report, please see What to expect after submission.
Thanks
Albert WWDR