Use case
You cannot hot-fix a string that is already in the store
On the web a bad translation is a deploy away from fixed. On mobile it is a review cycle away, in front of everyone who already downloaded it. The gate matters more here than anywhere else.
The formats you will be pulling
.xcstringsXcode string catalogs
.stringsiOS, macOS
strings.xmlAndroid
.arbFlutter
How the week goes
- 1Strings are pushed from the branchThe same CI job as everywhere else. Pin the API key to the mobile platform so a build runner can reach nothing else.
- 2Plurals are checked by language, not by EnglishPolish needs few and many; Arabic needs six forms. A missing form is reported by name rather than as a percentage.
- 3The release branch is gatedFail the job unless every locale you ship is complete. An exit code is the only warning anyone reliably reads.
- 4Files land in the bundle
pullreturns the platform's own format, so no conversion step sits between locoloop and Xcode or Gradle.
What to watch for
Ship-blocking is the feature
Gate the release, not the merge. Blocking every merge trains people to skip the check; blocking the release does not.
Length is a layout problem
German runs long and a button does not. Reviewing on the device beats reviewing in a spreadsheet, so keep reviewer seats free and hand them out.
Registers, once
Set formal or informal per locale before the first translation pass, not after someone re-reads every screen.
Set it up before the next release
Import the English file, enable a language, paste the CI job.