Continuous Localization in React Native and Swift without Slowing Sprints

Continuous localization is about integrating translation into agile development to enable uninterrupted multilingual content delivery Understanding Continuous Localization. In practice, this means new text strings are translated continuously as you code, rather than waiting for end-of-cycle localization. This approach fits perfectly with Agile workflows, eliminating tedious manual steps and allowing you to ship updates faster Continuous Localization Guide. In this blog post, we'll explore how to implement continuous localization for both React Native and Swift (iOS) projects using two popular platforms – Phrase (with its In-Context Editor) and Lokalise – all while maintaining sprint velocity.

We'll provide step-by-step setup guides for both Phrase and Lokalise in React Native and Swift, including code examples. We'll also compare Phrase vs. Lokalise in terms of developer workflow, integration ease, and support for continuous delivery. By the end, you should be able to add multilingual support to your app without slowing down your team's momentum.

React Native: Continuous Localization Pipeline

Adding localization in a React Native app usually involves an internationalization library and external translation files. Continuous localization builds on this by automating how those translation files are managed and updated. Below we cover setting up continuous localization with Phrase and Lokalise in React Native.

Using Phrase (with In-Context Editor) in React Native

1. Set Up Phrase Project: Start by creating a project in Phrase (formerly PhraseApp). This is your central hub for translation strings. Add your base language strings (e.g., English) to Phrase – you can upload a JSON, .po, or other supported resource file. Phrase will generate a Distribution (an OTA distribution for your app's strings) and an Environment Secret for secure access. Take note of these.

2. Install i18n Library and Phrase SDK: Phrase's React Native solution works with the popular i18next library Phrase SDK Documentation. If you haven't already, install react-i18next (or i18next and react-native-localize for language detection). Then install Phrase's RN SDK:

npm install react-native-phrase-sdk --save

This SDK enables over-the-air (OTA) translation updates in your app. Note: The Phrase RN SDK is designed to work with i18next for managing translation resources SDK Integration Guide.

3. Initialize Phrase in Your App: After installing, initialize the Phrase client at app startup (e.g., in your main App.js or a bootstrap module). For example:

import Phrase from 'react-native-phrase-sdk'
import i18n from 'i18next'
import { initReactI18next } from 'react-i18next'
import ChainedBackend from 'i18next-chained-backend'
import resourcesToBackend from 'i18next-resources-to-backend'

// Import your local fallback resources
import en from './locales/en.json'
import ru from './locales/ru.json'

const localResources = {
  en: { translation: en },
  ru: { translation: ru },
}

// Initialize Phrase OTA with your distribution and environment secret
const phrase = new Phrase(
  '<YOUR_DISTRIBUTION_ID>', // from Phrase project
  '<YOUR_ENVIRONMENT_SECRET>', // from Phrase project
  require('./package.json').version, // your app's version
  'i18next' // format (i18next v3/v4)
)

// Set up i18next backends: try Phrase first, fallback to local if offline or if no updates exist [Chained Backend Setup](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings). This means your app will always start with the latest translations available, without needing a full redeploy for text changes.
const backendPhrase = resourcesToBackend((language, namespace, callback) => {
  phrase
    .requestTranslation(language)
    .then((remoteResources) => callback(null, remoteResources))
    .catch((error) => callback(error, null))
})
const backendFallback = resourcesToBackend(localResources)

// Initialize i18next with chained backend (Phrase OTA + local)
i18n
  .use(ChainedBackend)
  .use(initReactI18next)
  .init({
    lng: 'en', // default language
    fallbackLng: 'en',
    backend: {
      backends: [backendPhrase, backendFallback],
    },
    interpolation: { escapeValue: false },
    // ... other i18n options
  })

In the above setup, the Phrase SDK is configured with your distribution ID and secret. It regularly checks for updated translations and downloads them in the background Background Updates. We use i18next-chained-backend to attempt loading translations from Phrase first, and fall back to bundled local JSON if offline or if no updates exist Chained Backend Setup. This means your app will always start with the latest translations available, without needing a full redeploy for text changes.

4. Enable the Phrase In-Context Editor (Optional): One of Phrase's standout features is the In-Context Editor (ICE), which lets translators edit translations right within the running app's UI ICE Documentation. For web apps, enabling ICE involves including a Phrase script snippet and using a post-processor that wraps each string. In a React Native context, the ICE is less straightforward (since there's no DOM), but if your RN app uses web views or if you have a web version, you can leverage this. Essentially, ICE ensures translators see exactly where text appears in the app, improving translation quality without developer intervention ICE Features. Even if you don't use ICE on device, you can still use Phrase's screenshot and context features to give translators UI references.

5. Developer Workflow with Phrase: With the above in place, your workflow becomes: developers add new translation keys in code (e.g., using i18n.t('welcome_message')), and those keys get synced to Phrase (either via Phrase's CLI, API, or a GitHub integration). Translators translate the strings in Phrase's platform (they can even use ICE on a web build for context). When translations are published, Phrase can bundle them into a new release for your distribution. The next time the app is launched (or periodically in background), the Phrase SDK will fetch the latest translations. Updated strings appear in the app instantly OTA Updates – no new app release needed. This continuous loop allows translation to happen in parallel with development, so it never blocks your sprint.

💡 Tip: Use the Phrase CLI or CI integration to automate syncing of new keys. For example, Phrase's GitHub integration can auto-pull source files from your repo and push translated files via pull requests GitHub Integration. This reduces manual steps and keeps developers focused on coding features, not managing JSON files.

Using Lokalise in React Native

Now let's set up continuous localization with Lokalise in a React Native app. Lokalise is a translation management platform known for its user-friendly interface Platform Overview and robust integrations. While it doesn't have a dedicated React Native SDK, it offers powerful CLI tools, APIs, and even mobile OTA SDKs for native platforms. In React Native, the typical approach is to treat Lokalise as the single source of truth for your translation files and automate their sync.

1. Set Up Lokalise Project: Sign up for Lokalise and create a new project for your app's translations (choose a base language like English). Note the project ID. Invite your translators or team members as needed. Lokalise's platform allows real-time collaboration with features like comments, screenshots for context, and even an in-app chat for queries.

2. Prepare Your Localization Library: As with Phrase, you'll need an i18n solution in React Native. You can use react-i18next or other libraries like react-native-localization or react-intl. The exact library is up to you; Lokalise supports exporting files in many formats (JSON, Android XML, iOS Strings, etc.) to match your library's needs File Format Support. For example, if you use i18next, you'll likely use JSON resource files.

3. Integrate Lokalise CLI for Continuous Sync: Lokalise provides a CLI tool (lokalise2) that can upload and download translation files. This is key for continuous localization, as you can script these actions in your build or deployment pipeline. Here's a step-by-step setup using the CLI CLI Setup Guide:

• Install the Lokalise CLI CLI v2 (available via npm or as a binary). For example:

  npm install -g lokalise2
  

• Generate an API token from your Lokalise account (Profile > API tokens). This token will authorize CLI calls.

• In your project, add your existing translation files (e.g., en.json, fr.json in a locales or resources folder). If you don't have any yet, you can create a simple JSON with a couple of keys for testing.

• Upload base language files: Use the CLI to push your source strings to Lokalise. For example:

  lokalise2 file upload --token <API_TOKEN> \
    --project-id <PROJECT_ID> \
    --lang-iso en \
    --file ./locales/en.json
  

  This command uploads your English JSON to Lokalise as the source content Upload Process. Repeat for other existing locale files (adjusting --lang-iso and file path for each). After uploading, your Lokalise project will list all keys and their text. Translators can now log in to Lokalise and start translating the keys through its web UI.

• Download translated files: Once translations have been added or updated in Lokalise, you can pull them down. For example:

  lokalise2 file download --token <API_TOKEN> \
    --project-id <PROJECT_ID> \
    --format json \
    --bundle-structure "%LANG_ISO%.json" \
    --unzip-to ./locales/
  

  This fetches all languages as individual JSON files (named by language code) and saves them into your locales folder Download Guide. You can run this regularly (even automate it in CI) to get the latest translations.

4. Use the Localized Files in React Native: After downloading, include these JSON files in your app bundle or load them at runtime. If using i18next, you might initialize it with the files similarly to the Phrase example (but without the Phrase backend). For instance:

import i18n from 'i18next'
import { initReactI18next } from 'react-i18next'
import * as RNLocalize from 'react-native-localize'

// Import the locale JSON files
import en from './locales/en.json'
import fr from './locales/fr.json'

const resources = {
  en: { translation: en },
  fr: { translation: fr },
}

i18n.use(initReactI18next).init({
  resources,
  lng: RNLocalize.getLocales()[0]?.languageCode || 'en', // device language
  fallbackLng: 'en',
  interpolation: { escapeValue: false },
})

This basic setup will allow you to use i18n.t('your_key') in React components (via the useTranslation hook or HOC) to display localized strings. After each sync from Lokalise, your JSON files update – you just need to rebuild or reload the app in development to see changes. To truly avoid rebuilds, you could fetch translations at runtime from an API, but in practice, pulling via CLI and including in the bundle is simpler and reliable for continuous delivery (and can be automated before each release).

5. Automate the Workflow: The key to not slowing down sprints is automation. Integrate the Lokalise CLI commands into your build or release pipeline. For example, you might have a GitHub Action or CI job that on each merge to main, runs lokalise2 file upload to push new keys from source, and another that periodically runs lokalise2 file download to update the repo with new translations (possibly gating it behind translator completion). Lokalise also supports a two-way sync with GitHub – you can connect your repository so that new strings are auto-detected and sent for translation, and translated files are sent back via pull requests lokalise.com. This means developers don't need to manually handle language files at all during a sprint. They just use keys in code, and translations flow in behind the scenes.

6. Keep Translators in the Loop: Lokalise's platform provides features to maintain translation quality without developer oversight: in-context screenshots, comments, and discussion threads on each string lokalise.com. Make it a habit to upload screenshots of your app screens to Lokalise (there's even an API or SDKs to automate capturing these). Translators can then see where text appears and translate with context, reducing back-and-forth clarifications. This parallelizes work – devs and translators work simultaneously, and fewer bugs are filed later for poor wording or context issues.

By using Lokalise in this continuous way, adding a new feature with text in a sprint looks like: Developer adds a key (it gets synced to Lokalise), translator immediately sees it and translates (perhaps even within the same day), and by the time you're ready to release or test, you pull latest translations. Sprint velocity remains high because localization is not a separate phase – it's integrated into the development flow.

iOS (Swift): Continuous Localization Pipeline

For native iOS (Swift) projects, continuous localization revolves around using .strings files or .stringsdict and automating their updates. Both Phrase and Lokalise offer iOS SDKs to enable OTA (over-the-air) updates of localization without app releases. Let's see how to integrate each into a Swift app.

Using Phrase in iOS (Swift)

1. Set Up Phrase Project: Similar to RN, create a project in Phrase for your iOS app if you haven't already. If your app already has Localizable.strings files, you can upload them to Phrase (via the Phrase CLI or web UI). Otherwise, you can push keys from code later. Ensure you have an OTA Distribution ID and an Environment Secret from Phrase (Phrase's OTA is part of what they now call Phrase Strings). These will identify your app and environment to the Phrase service.

2. Add the Phrase iOS SDK: Phrase provides an iOS SDK (called PhraseSDK) that you can install via Swift Package Manager, CocoaPods, or Carthage – choose whichever fits your project. For example, using CocoaPods, add this to your Podfile:

pod 'PhraseSDK'

Then run pod install to integrate. (If using SPM, you'd add the GitHub repo https://github.com/phrase/ios-sdk/ in Xcode's Swift Packages SDK Installation.)

3. Initialize Phrase SDK in App Delegate: In your App Delegate (or the entry point of your app), import the SDK and set it up with your credentials:

import PhraseSDK

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Optional: enable debug mode for Phrase (to see logs in development)
        Phrase.shared.setDebugMode(true)
        // Initialize Phrase OTA with your distribution and secret
        Phrase.shared.setup(distributionID: "<DISTRIBUTION_ID>",
                              environmentSecret: "<ENV_SECRET>")
        // Fetch latest translations from Phrase server
        Phrase.shared.updateTranslation()
        return true
    }
}

With the above, when your app launches, it connects to Phrase's server to pull down any updated localization data for the current app version SDK Setup Translation Updates. Under the hood, Phrase's iOS SDK uses method swizzling on Bundle.main to intercept calls to NSLocalizedString. This means after you call updateTranslation(), any NSLocalizedString("some_key", ...) in your app will first check Phrase's updated strings. If a new translation exists from Phrase, it will use it; otherwise it falls back to your compiled .strings file. For example, if you have NSLocalizedString("welcome_message", nil) in your code, and a translator updated "welcome_message" text in Phrase, the updateTranslation() call will ensure that when this line executes, you get the updated text.

Phrase also offers a direct API to fetch translations if needed. For instance, Phrase.shared.localizedString(forKey: "welcome_message", value: nil, table: nil) will retrieve the latest string for that key Direct API Usage. However, in most cases you can continue using NSLocalizedString in your Swift code as usual and let the swizzling auto-redirect to Phrase's updated bundle.

4. Manage Releases in Phrase: To maintain continuous delivery, you'll typically use Phrase's web console to publish releases of translations. Phrase ties translation distributions to app versions – for example, you might tag a set of translations as "Release 1.0". In the SDK initialization above, we passed the app version. Phrase will deliver the latest released translations matching that version. This allows you to control when translators' work goes live. A good practice in agile sprints is to create a Phrase release at the end of each sprint or just before a deployment, so that the SDK will pick up exactly those translations. If you have multiple environments (dev, staging, prod) you might use different Distribution or Environment IDs (as provided by Phrase) or simply only publish releases when ready for production.

5. Continuous Workflow with Phrase (iOS): Once integrated, developers simply use NSLocalizedString for any user-facing text. When a new string is added, run the Phrase CLI to upload the updated .strings file or use an integration (Phrase can connect to GitHub and automatically import new strings files on pushes). Translators or localization managers then translate in Phrase's UI – they can use features like the In-Context Editor on a web demo of the app, or refer to screenshots for context. After translations are done (or incrementally as they are done), you publish a new release in Phrase for the current app version. The next time a user opens the app, Phrase.shared.updateTranslation() will fetch those new translations. The process is continuous and parallel: no need to freeze development or wait for a full app update to ship new or corrected translations Continuous Localization. This keeps your release cycles short and your global audience happy with up-to-date translations.

Using Lokalise in iOS (Swift)

For Lokalise, the approach on iOS can be either file-based (downloading .strings files via CLI and bundling them) or using Lokalise's Over-The-Air (OTA) SDK for iOS. The OTA SDK is a more advanced route that allows live updating of strings similar to Phrase's. We'll focus on the SDK method since it best supports continuous localization.

1. Set Up Lokalise Project & Token: Ensure you have a Lokalise project for iOS. Typically, you'd upload your base Localizable.strings file to Lokalise (either by drag-and-drop in the UI or using lokalise2 file upload similar to the RN steps). Once your keys are in Lokalise, get an SDK token from the project settings (Lokalise requires a special read-only token for the SDK). Also note the project ID.

2. Generate a Lokalise Bundle: In Lokalise, go to Downloads and select "Lokalise iOS SDK" as the format, then click Build to generate an initial bundle of translations Bundle Generation Bundle Management. Lokalise uses the concept of versioned bundles for OTA – each bundle is a snapshot of all translations. You can manage multiple bundle versions (e.g., for different releases or testing) in Lokalise's UI Bundle Versioning. For now, generate a bundle that includes your current translations. (Later on, whenever new translations are added, you'll create a new bundle version and publish it – this can also be done via API.)

3. Install Lokalise iOS SDK: The Lokalise SDK is distributed as a CocoaPod named Lokalise (and also available via Carthage or SPM). To install via CocoaPods, add:

pod 'Lokalise'

Then pod install. This brings in the Lokalise framework to your project SDK Installation Framework Setup.

4. Initialize Lokalise SDK in App Delegate: In your App Delegate, configure the Lokalise SDK with your project details:

import Lokalise

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Configure Lokalise with your Project ID and SDK token
        Lokalise.shared.setProjectID("<PROJECT_ID>", token: "<SDK_TOKEN>")
        // Enable swizzling to override NSBundle for .strings lookup
        Lokalise.shared.swizzleMainBundle()
        // (Optional) Immediately check for updates on launch
        Lokalise.shared.checkForUpdates { (updated, error) in
            print("Updated: \(updated), Error: \(String(describing: error))")
        }
        return true
    }
}

Let's break down what this does. The call to setProjectID(_, token:) authenticates the SDK and points it to your Lokalise project SDK Configuration. The swizzleMainBundle() call tells Lokalise to swizzle the main bundle, so that calls to NSLocalizedString will fetch from Lokalise's loaded data rather than the compiled app bundle Bundle Swizzling. Finally, checkForUpdates will contact Lokalise's server to see if a newer translation bundle is available, download it if so, and automatically replace the in-app strings with the new ones Update Process. Lokalise recommends calling checkForUpdates at app launch and also whenever the app resumes from background (to catch updates during runtime) Update Recommendations. The completion handler is optional, but useful for logging or to know when an update has applied.

5. Using Lokalise OTA in the App: After the above integration, your code uses NSLocalizedString as usual or alternatively Lokalise.shared.localizedString(forKey: "key", value: nil, table: nil) for custom usage String Localization. If swizzling is enabled, interface elements in storyboards or XIBs will also get localized text from Lokalise's bundle (as long as you've localized those in Interface Builder with the usual Localizable.strings). The Lokalise SDK supports instant UI language switching as well SDK Features. For example, if your app allows the user to change language at runtime, you can call Lokalise.shared.setLocale("fr") and it will immediately use French strings (assuming you've downloaded that locale in the bundle).

6. Continuous Workflow with Lokalise (iOS): On Lokalise's dashboard, whenever new keys or translations are added, you will create a new bundle version and publish it (mark it as "Release" or "Prerelease"). The SDK by default looks for released bundles (you can configure it to fetch prerelease bundles for testing) Bundle Release Process. In a continuous localization setup, you might choose to generate and publish a new bundle at the end of each sprint or even more frequently. Lokalise provides an API to automate bundle creation, which you could invoke from your CI pipeline when new translations are merged. Once a bundle is published, any user opening the app (with the SDK integrated as above) will silently get the update. The result: text changes and new languages appear in your app without requiring an App Store update, accelerating your international releases.

7. Keeping Velocity High: From a developer perspective, using Lokalise OTA means you rarely have to deal with .strings files directly. You add keys in code, push the base strings to Lokalise (via CLI or Git integration), and that's it. Your main responsibility is to ensure the Lokalise SDK is initialized and checkForUpdates() is called appropriately. The translation team or localization manager handles the rest in Lokalise's UI. Lokalise's platform also has features like screenshots and context notes (similar to Phrase) to help translators understand each string Translation Quality. By leveraging these, you reduce the likelihood of translation errors that require developers to clarify or make multiple revisions. Consequently, your sprint keeps moving forward with minimal interruptions for localization issues.

Phrase vs. Lokalise: Comparison for Continuous Localization

Both Phrase and Lokalise enable continuous localization, but there are differences in developer workflow, integration, and capabilities. Below is a comparison of key aspects:

Both platforms support the core goal: maintaining development velocity while adding multilingual support. Your choice may depend on team preferences: Phrase offers a slightly more developer-centric approach with in-app editing capabilities, whereas Lokalise shines in its user-friendly interface and broader integration ecosystem.

Maintaining Sprint Velocity with Multilingual Support

Continuous localization allows you to treat translations as a parallel process, not a gated step. Here are some final tips to ensure you maintain your sprint velocity while implementing multilingual support:

• Integrate Early: Start the localization setup early in the project. It's easier to build internationalization (i18n) into features from the beginning than to retrofit later. By having Phrase or Lokalise pipelines ready, every sprint can include localization tasks as part of "definition of done."
• Automate Everything: Leverage CLI tools, CI/CD scripts, and repository integrations to handle syncing of translation resources. Automation means developers spend near-zero time on managing translation files. For example, a GitHub Action could run lokalise2 download nightly so that your locales/ stay up to date, or Phrase's Git integration could auto-commit new translations to a branch.
• Parallelize Work: Encourage your translators to work continuously alongside development. In each sprint, as soon as a developer adds or changes a user-facing string, it should flow to the translation platform. This avoids large last-minute translation efforts. Both Phrase and Lokalise enable continuous translation workflows so that by the time you're ready to release a feature, translations are either done or mostly done.
• Use OTA Updates for Flexibility: By using over-the-air translation delivery (Phrase or Lokalise SDKs), you decouple text updates from binary releases. This means if a translation comes in slightly late or a typo is fixed after a release, you can still deliver it to users immediately. It removes the pressure to "get all translations in by code freeze," thereby reducing stress on both devs and translators.
• Monitor and Iterate: Treat your localization process with the same agility as your development process. Monitor how often missing translations or context issues occur and use the platform's tools to address them (e.g., add more screenshots, use the In-Context Editor or Lokalise's preview functionality). Continuous localization is an iterative process of improvement. Over time, you'll refine workflows that best suit your team, whether it's adjusting when you generate Lokalise bundles or how you name keys for clarity.

By following the above practices and leveraging the capabilities of Phrase or Lokalise, you ensure that adding multilingual support doesn't slow down your team. On the contrary, it becomes a natural part of your development cycle. As Phrase notes, modern localization technology can integrate into agile development and **speed up release cycles in each target market"phrase.com. Lokalise similarly emphasizes eliminating manual steps so you can **deliver products to end-users faster"lokalise.com.

Conclusion

Going global with your app no longer means compromising on agility. Continuous localization with tools like Phrase and Lokalise enables your development and translation workflows to move in tandem. We've seen how to set up robust pipelines in React Native and iOS projects – from installing SDKs and writing initialization code to automating file sync and OTA updates. The Phrase vs. Lokalise comparison shows that both platforms support an agile approach to localization, each with its own strengths in workflow and features.

By maintaining a single source of truth for translations and integrating it tightly with your codebase, you empower your team to deliver new features with multilingual support from day one. Developers write the code and define keys; translators see the changes in context and localize them; the latest translations flow back into the app either at build time or instantly over the air. All of this happens continuously, in the background, so your sprint goals stay on track.

In an increasingly global market, having a scalable, continuous localization process is a competitive advantage. It ensures that expanding to new languages or updating copy is a non-event rather than a fire drill. With Phrase or Lokalise set up, you can confidently say "yes" to adding that new language or tweaking that welcome message mid-sprint – your pipeline has you covered. Keep coding, keep translating, and keep your sprint velocity high!

Sources: The insights and code examples above draw from official Phrase and Lokalise documentation and industry best practices. Key references include:

• Phrase's guides on continuous localization Understanding Continuous Localization and Agile Localization Best Practices

• OTA SDK usage Phrase OTA Setup Guide and SDK Implementation Details

• Lokalise's tutorials on React Native Integration and iOS SDK Setup

Both platforms have extensive docs and support to help you tailor the setup to your needs – be sure to consult them as you implement your continuous localization pipeline. Enjoy your agile localization journey!