LocalizeTo
Sign in

iOS localization

Translate your iOS, iPadOS, macOS, watchOS or tvOS app with Localize.to. Manage your strings in one place, pull a native Localizable.strings or modern String Catalog (.xcstrings), drop it into Xcode, and ship in every language your users speak.

Two Apple-native formats

Apple has two string formats, and Localize.to emits both. Pick the one that matches your project:

Fetch Localizable.strings

Every project has a read key (see the API tab inside a project). Pass it as ?apikey= and add &format=ios:

curl "https://api.localize.to/v1/language/en?apikey=READ_KEY&format=ios" \
  -o YourApp/en.lproj/Localizable.strings

The endpoint returns a standard Apple strings file:

"sign_in" = "Sign in";
"sign_out" = "Sign out";
"welcome" = "Welcome, %@";

Quotes and newlines inside a value are escaped for you, so the file is always valid Apple strings syntax.

Fetch a String Catalog (.xcstrings)

A String Catalog ships every language in one JSON file — perfect for new Xcode projects. The endpoint bundles all enabled languages automatically; you do not call it per language:

curl "https://api.localize.to/v1/language/en?apikey=READ_KEY&format=xcstrings" \
  -o YourApp/Localizable.xcstrings
{
  "sourceLanguage": "en",
  "version": "1.1",
  "strings": {
    "sign_in": {
      "localizations": {
        "en": { "stringUnit": { "state": "translated", "value": "Sign in" } },
        "sk": { "stringUnit": { "state": "translated", "value": "Prihlásiť sa" } }
      }
    }
  }
}

The language you pass in the URL becomes the catalog's sourceLanguage. Every enabled project language is included.

Build-time integration

The cleanest integration is a small script that pulls strings before Xcode builds. Add a Run Script build phase in your target, or call it from CI before xcodebuild.

#!/usr/bin/env bash
# Localizable.strings — one call per language
set -euo pipefail
API="https://api.localize.to/v1"
KEY="${LOCALIZE_READ_KEY:?set LOCALIZE_READ_KEY}"

for lang in en sk uk; do
  dir="YourApp/$lang.lproj"
  mkdir -p "$dir"
  curl -fsSL "$API/language/$lang?apikey=$KEY&format=ios" -o "$dir/Localizable.strings"
done
#!/usr/bin/env bash
# Localizable.xcstrings — one call, all languages
set -euo pipefail
API="https://api.localize.to/v1"
KEY="${LOCALIZE_READ_KEY:?set LOCALIZE_READ_KEY}"

curl -fsSL "$API/language/en?apikey=$KEY&format=xcstrings" \
  -o YourApp/Localizable.xcstrings

Using the strings in your app

// Swift
let label = String(localized: "sign_in")
let greeting = String(format: String(localized: "welcome"), userName)

// SwiftUI
Text("sign_in")
Text("welcome \(userName)")

With SwiftUI and iOS 15+, Text("sign_in") auto-looks-up the key in the bundled strings file or String Catalog — no wrapper function needed.

Key naming tips

Apple allows any string as a key, but stable, developer-facing identifiers (sign_in, screens.checkout.submit) are easier to manage than English sentences as keys. Localize.to encourages the same convention and stores a description per key that you can expose as a translator note in the String Catalog workflow.

Other formats

The same API serves android, json, xml, csv and php. See the Developers page for a full walkthrough and the API page for the endpoint reference.

Next steps