Most indie apps ship in English, maybe add a handful of "big" languages later, and call it done. I went the other way: Cadento, my SwiftUI Pomodoro/focus timer, launched in 39 languages on day one — including ones most apps never touch, like Catalan, Croatian, Malay, Hebrew, Thai, and Ukrainian.

This post is the honest version of how that went: the setup that made it possible, the things that broke, and whether it was worth it.

Cadento is built with SwiftUI + SwiftData, targets iOS 18 / watchOS 11, and has Live Activities, widgets, an Apple Watch app, an activity heatmap, and iCloud sync. App Store: https://apps.apple.com/app/id6784636854

Why 39 languages, not 5

The usual advice is "localize into the top languages and measure." That's reasonable. But for a focus timer, the UI vocabulary is small and stable — "Start", "Focus", "Break", "Tasks", "Today", "Streak". Once I had a clean localization pipeline, the marginal cost of language #20 was close to zero. And every additional language is a market where almost no competitor has a localized listing.

So the real question wasn't "is each language worth it?" — it was "can I make adding a language nearly free?" If yes, you do all of them.

The foundation: one .xcstrings file

The whole thing rests on Xcode's String Catalog (.xcstrings), introduced in Xcode 15. Instead of one Localizable.strings per language, you get a single JSON file with the source language and every translation nested under each key:

{
  "sourceLanguage" : "en",
  "strings" : {
    "timer.start" : {
      "localizations" : {
        "en" : { "stringUnit" : { "state" : "translated", "value" : "Start" } },
        "ja" : { "stringUnit" : { "state" : "translated", "value" : "開始" } },
        "ar" : { "stringUnit" : { "state" : "translated", "value" : "ابدأ" } }
      }
    }
  }
}

Why this matters for a solo dev:

• One file is diffable, scriptable, and reviewable. No 39 files drifting out of sync.
• Each translation carries a state — new vs translated — so you can programmatically find every untranslated key across all languages.
• In code you just use the key. No NSLocalizedString boilerplate spread everywhere.

That state field turned out to be the single most useful thing in the entire workflow. It's a built-in to-do list.

The actual locale list

39 isn't a round marketing number — it maps to real App Store storefronts, including regional variants where the wording genuinely differs:

en, en-GB, en-AU,
ar, ca, cs, da, de, el, es, es-419, fi, fr, fr-CA, he, hi, hr, hu,
id, it, ja, ko, ms, nb, nl, pl, pt-BR, pt-PT, ro, ru, sk, sv,
th, tr, uk, vi, zh-Hans, zh-Hant, zh-HK

Note the regional splits: es vs es-419 (Spain vs Latin America), pt-BR vs pt-PT, zh-Hans/zh-Hant/zh-HK. These aren't vanity — a button label or a date phrasing that's correct in São Paulo can read slightly off in Lisbon.

What actually broke

Localizing isn't translating strings. It's everything around the strings.

1. Layout overflow. German and Finnish expand text by 30–40%. A button that fit "Start" in English clipped its label in German. The fix is boring but mandatory: stop hard-coding widths, let SwiftUI size to content, and test the longest language, not the shortest. German is your stress test.

2. Right-to-left. Arabic and Hebrew flip the entire layout. SwiftUI handles a lot automatically if you use leading/trailing instead of left/right — but custom drawing (progress rings, the heatmap) needed explicit attention so it didn't mirror into nonsense.

3. Dates, numbers, plurals. Never build a string like "\(count) sessions". Plural rules differ wildly (Arabic has six plural categories). String Catalog supports plural variations per language — use them, or your "1 sessions" will haunt you.

4. The "translated but wrong" trap. A state: translated flag means a translation exists, not a good one. For high-traffic UI I had key phrases reviewed; for the long tail I accepted "good enough and fixable." Being honest about that tradeoff is the only way 39 languages is sustainable solo.

Was it worth it?

For a focus timer with a small, stable vocabulary: yes, clearly. The cost was front-loaded into building the pipeline once. After that, the app shows up localized in storefronts where every competitor is English-only — and "this app speaks my language" is a real conversion lever in places the big apps ignore.

If your app has a sprawling, constantly-changing text surface (think a social app with dynamic content), the math is different and you should be more selective.

Takeaways

• Use the String Catalog (.xcstrings). One file, scriptable, with per-string translation state.
• Let the state field be your untranslated-work tracker.
• Test German/Finnish for overflow, Arabic/Hebrew for RTL — those four catch most layout bugs.
• Never concatenate counts into strings. Use plural variations.
• Decide your quality bar per tier (core UI vs long tail) and be honest about it.

If you want the deeper writeup — including how I auto-generated localized App Store screenshots for all 39 languages — that's the next post.

I'm a solo iOS developer from Japan building small, deeply localized apps. Cadento (focus timer, 39 languages) is on the App Store. Happy to answer i18n questions in the comments.