DevOps / CI·CD 7. Mai 2026

2026-05-07 iOS String Catalog (xcstrings)Lokalisierung CI-Gates auf gemietetem Apple-Silicon-Cloud-Mac (HK / JP / KR / SG / US)

MacXCode Engineering Team 7. Mai 2026 ~24 Min. Lesezeit

String-Drift zerstört App-Store-Einreichungen leise: Screenshots wirken auf Englisch gut, aber Kürzungen, fehlende Pluralregeln oder veraltete Varianten tauchen erst auf, wenn QA die Systemsprache auf einem Gerät wechselt, das niemand physisch hält. Xcode String Catalogs (.xcstrings) bündeln das—aber Teams mit gemietetem Mac mini M4 in HK/JP/KR/SG/US brauchen einen CI-Vertrag: Kataloge pro PR validieren, XLIFF exportieren, Import mit Konflikterkennung, mindestens ein automatisierter UI-Lauf pro geschäftskritischer Locale. Dieser Leitfaden 2026-05-07 verbindet operative Details, die Release Notes selten nennen—xcodebuild schnell halten bei 12+ Locales, Ausrichtung an parallelen Jobs, und DerivedData nicht aufblasen, wenn Lokalisierungsassets neu generiert werden—siehe Isolation pro Job. Teilen sich Dependency-Auflösung und Host, kombinieren Sie das mit SwiftPM-Cache-Hygiene, damit Exporte und Package-Resolve nicht um dieselbe NVMe-Warteschlange konkurrieren.

Warum Lokalisierung zuletzt bricht

Funktionstests laufen auf Englisch; Marketing genehmigt Decks ohne Repo; Übersetzer bekommen ZIPs, die beim Return schon alt sind. Catalogs heilen keine Prozesse—sie liefern ein einzelnes Artefakt zum Git-Diff. CI soll fehlende Schlüssel, kaputte Plurale oder illegale Platzhalter so laut machen wie Compilerfehler.

Anker: Merge blocken, wenn irgendeine Pflichtlocale eine Übersetzung für in der PR eingeführte Schlüssel fehlt—wie ein roter Unit-Test.

xcstrings vs verteilte .strings / stringsdict

Legacy-Splitts verpassen Löschungen in Reviews. .xcstrings bündelt Metadaten, Zustände und Varianten—Automation einfacher, Merge-Konflikte häufiger. Halten Sie eine Kompatibilitätsmatrix während der Migration und entfernen Sie duale Quellen schnell.

Qualitätsgates in GitHub/GitLab

  • Syntaxvalidierung — gleiches DEVELOPER_DIR wie Release.
  • Schlüsselabdeckung — scheitern, wenn NEW_KEY in Tier-1-Locales nicht translated ist.
  • Platzhalterparität%@, %d, Positionsparameter müssen passen.
  • Screenshot-Lint — optional; mit Screenshot-Tests mindestens eine Nicht-Englisch-Locale nachts.

Import/Export-Runbook für Headless-Builder

Nur SSH: wiederholbare Kommandos statt GUI-Klicks.

xcodebuild -exportLocalizations -project YourApp.xcodeproj -localizationPath ./exports xcodebuild -importLocalizations -project YourApp.xcodeproj -localizationPath ./imports

Exports auf demselben NVMe wie IPA-Export & ASC-Uploads, damit Rechte und umask konsistent bleiben. Immer als CI-User, nie als root.

XLIFF-Roundtrip-Hygiene

Übersetzer brauchen stabile IDs; Engineers deterministische Imports. XLIFF versionieren oder mit Checksum-Tags im Objektspeicher ablegen. Imports ablehnen, die Schlüssel ändern, die nicht im Basiskatalog sind, oder note-Felder entfernen. Multi-Region-Regeln (zh-Hans vs zh-Hant) in YAML kodieren.

Merge-Tipp: XLIFF-Konflikte wie Code—nie „beides“ ohne Platzhalter-Reconciliation.

Plurale, Geräte und Breitenvarianten

Moderne Apps brauchen gerätespezifische Breiten für Watch-Komplikationen, Dynamic-Type-Screenshots und Kurzbefehle. Varianten nur, wenn die QA-Matrix sie listet. Pflicht vs. best effort dokumentieren und in CI-Schwellen spiegeln.

Parallele Locale-Matrix ohne Host-Schmelze

Jede zusätzliche Locale multipliziert XCTest-Asset-Arbeit. Begrenzen Sie gleichzeitige Destinationen wie bei parallelen xcodebuild-Jobs. Sharding: Lane A Ostasien, B Europa, C RTL-Smoke. Wächst p95 quartalsweise um mehr als 25 %, zweiten Knoten näher zu den Übersetzern mieten.

Disk, DerivedData und Lokalisierungs-Caches

Imports/Exports berühren tausende kleine Dateien—ideal, um APFS-Metadaten zu stressen. Vor vollem Export mindestens 18 % frei halten; alte XLIFF-Drops archivieren. TMPDIR + xcresult-Isolation, damit Lokalisierungsjobs keine Artefakte anderer Pipelines löschen.

Numerische Ziele für interne SLAs

  • 100 % Tier-1-Abdeckung vor RC-Tag.
  • 0 ungelöste stale-Schlüssel älter als 14 Tage.
  • < 12 Minuten für inkrementelle Lokalisierungsvalidierung typischer PRs.

Neun-Schritte-Checkliste vor String-Freeze

  1. Produkttexte einfrieren; Vendor mit Commit-SHA informieren.
  2. Baseline-XLIFF vom Release-Branch exportieren.
  3. Katalog mit dem Xcode wie App Store validieren.
  4. Vendor-Dateien auf Wegwerfbranch importieren; JSON-Zustände diffen.
  5. UI-Smoke in drei Locales: LTR, RTL, CJK.
  6. App-Store-Metadaten prüfen, falls synchron.
  7. du -sh auf Lokalisierungsverzeichnissen snapshotten.
  8. Merge taggen; Checksum-Manifest für Compliance anhängen.
  9. Post-Release-Audit für needs_review planen.

FAQ: App-Store-Review, CI-User, hybride Pods

FrageAntwort (2026-05-07)
CocoaPods + SPM Hybrid?Ja—nach Dependency-Auflösung lokalisieren, damit generierte Bundles existieren; siehe SwiftPM vs CocoaPods.
UI-Tests bei Tippfehler überspringen?Nur bei reinem Whitespace und nachgewiesen durch Policy-Bot—sonst mindestens einen Nicht-Englisch-Smoke.

Warum Mac mini M4 mit 1–2 TB für lokalisierungslastige CI

Lokalisierungs-Pipelines sind metadaten-zufällig: viele kleine Dateien hammern denselben NVMe wie xcodebuild test. Bare-Metal-Mac mini M4-Knoten halten Latenz planbar. Kapazität: regionale Preise; Onboarding: Hilfe.

NVMe-Puffer vor der nächsten Lokalisierungswelle

Mac mini M4 · HK / JP / KR / SG / US · SSH / optional VNC