The CLI and the SDKs solve different problems, and in many projects, you’ll use both.
The CLI handles the pipeline side: uploading source strings to Localazy and downloading completed translations back into your build. It works at the file level — it reads your Android .xml or iOS .strings/.xcstrings files, syncs them with Localazy, and writes the translated versions back to disk as part of your build process. There’s no library added to your app, and no runtime dependency. For teams that want clean separation between localization tooling and the app itself, the CLI-only approach is a solid choice.
The Android Gradle plugin and iOS Swift SDK go a step further by enabling over-the-air (OTA) translation updates. Once the SDK is integrated into your app, new or corrected translations can be delivered directly to users through Localazy’s CDN without requiring an app store update or a new release. The SDK handles caching, locale detection, and only downloads what’s changed. For mobile teams that need to fix translation errors quickly or launch new languages between releases, this is a significant practical advantage.
The tradeoff is integration depth. The SDK adds a lightweight runtime dependency to your app and requires initialization in your application class (Android) or app delegate (iOS). The CLI requires no app-level changes at all.
A common setup: use the CLI in your CI/CD pipeline to keep source strings and translations in sync during development, and integrate the SDK for production OTA delivery. If you build for both Android and iOS, the CLI can manage both platforms from a single workflow, handling format conversion automatically between the two.
Please help us with improving our documentation.
We appreciate all your feedback.