Store the String Catalogs the way Xcode serializes them, so an IDE build leaves the tree clean

[kyleve]

The problem

Building the Where app in Xcode rewrote Where/WhereUI/Sources/Resources/Localizable.xcstrings with ~5,500 changed lines, leaving the working tree dirty after every IDE build. That makes it easy to commit thousands of lines of noise by accident, and easy to miss a real change in git status.

The diff was almost entirely serialization: the checked-in files wrote "sourceLanguage": "en", Xcode writes "sourceLanguage" : "en" — on every line of the file.

The cause

Xcode rewrites a .xcstrings in place during an IDE build whenever string extraction finds a key the catalog doesn't have yet — and when it does, it writes the whole file with its own serializer. That serializer is Foundation's pretty-printed JSON: two-space indent, a space before the colon, keys sorted by code point, no trailing newline.

Four of the seven catalogs were written by the String Catalog symbol-generation migration in #124 with a script's json.dump instead of by Xcode, so they parsed identically but differed on every line. Extraction also had four keys to add, which is what triggered the rewrite in the first place — so the one real addition arrived buried under a full reserialization.

Two things worth knowing, since neither is obvious:

• xcodebuild never does this write-back — only the IDE does. So CI stayed green and clean while local builds churned, and "build it from the CLI and see" doesn't reproduce the bug.
• xcstringstool sync is not the fix. It's the staleness half of the IDE's pass; run standalone it deletes every value-less auto-extracted entry, including the 26 isCommentAutoGenerated ones in WhereIntents that have been checked in and surviving IDE builds since Adopt String Catalog symbol generation across the app #124. Only the IDE's add half puts them back.

What changed

• All seven catalogs are now byte-identical to what Xcode writes (including dropping the trailing newline — Xcode's serializer doesn't emit one). Five changed formatting only; the three that were already in Xcode's style (WhereCore, RegionKit, LifecycleKit) only lost that newline.

• The four auto-extracted entries Xcode kept re-adding are committed, as the empty entries it writes them as. They come from literals extraction picks up:

  Entry	Source
  ""	Marker("", coordinate:) in RecordedPointsMap
  %lld	Text("\(group.outlineCount)") in RegionMapView, Text("\(day.dayOfMonth)") in CalendarContentView
  Log today here	a Button literal in an IntentSnippets #Preview
  App content	a LifecycleContainer #Preview (LifecycleKit)

• ./xcstrings normalizes catalogs in Xcode's serialization, with --lint to check. It touches formatting only — content belongs to Xcode and the translators, and it re-parses its own output and refuses to write if anything moved. Reproducing Foundation byte-for-byte needs one deviation: its .sortedKeys compares case-insensitively while Xcode sorts by code point, which shows up the moment a catalog holds an auto-extracted capitalized literal next to a lowercase key.

• CI lints it, as a step in the existing format job (branch protection pins the two check names, so this rides along rather than adding a job).

• Docs: the invariant and the script in AGENTS.md; what the auto-extracted entries are and how to actually get rid of one in Where/AGENTS.md.

Verification

• No content changed anywhere. Comparing parsed JSON against HEAD: no key, value, comment, state, or extractionState differs; the only deltas are the four added entries.
• Idempotence. After a wiped DerivedData and a cold tuist build Where (which builds the widgets, share extension, and every catalog-owning package target), git status is clean. Repeated after the full test scheme — also clean. The IDE's trigger is gone too: reading the .stringsdata that build emitted, every extracted key is already in its catalog for all seven, so the IDE has nothing to add and therefore nothing to reserialize.
• Cross-checked against Xcode itself. The entries were derived from build .stringsdata, and the result is byte-identical to what Xcode had written into WhereUI's (4,200-line) and LifecycleKit's catalogs on its own — so this is Xcode's converged output, not an imitation of it.
• ./swiftformat --lint clean (0/563 files). Full Stuff-iOS-Tests scheme green on iPhone 17 / iOS 27.0 — 1,380 tests, 0 failures, including WhereFormatTests.generatedSymbolsResolveToCatalogValues.

Deliberately not fixed

The four source literals behind those entries. Removing an entry for good means removing the literal, and a couple are worth fixing on their own terms — the interpolated Text("\(Int)") sites skip WhereFormat's number styling, the preview Button hardcodes copy the snippet.logTodayHere symbol already owns, and the empty Marker("") label says nothing to VoiceOver. That's app-source work rather than serialization, so it's filed in Where/TODOs.md instead of done here.