Remote strings on iOS: update app text without a new build

Why do iOS apps need remote strings?

The standard way to manage text in iOS apps involves compiling `Localizable.strings` files or String Catalogs directly into your application bundle. While effective for initial development, this method creates a significant bottleneck for ongoing content updates. Any change, whether it is a minor typo correction, a marketing copy adjustment, or an urgent translation update, necessitates creating a new app version, submitting it to the App Store, and waiting for Apple's review process.

This traditional workflow can delay critical content changes by days or even weeks, impacting your ability to respond quickly to market demands or user feedback. For product and marketing teams, this means missed opportunities and a lack of agility. Implementing remote strings allows you to bypass this cycle, enabling immediate updates to your app's UI text. This capability aligns with the App Store Review Guidelines, which generally permit dynamic content updates as long as they do not fundamentally change the app's core functionality or violate other policies.

How iOS localization works by default and its limits

By default, iOS apps use `NSLocalizedString` to fetch text from `Localizable.strings` files, which are organized by language. Xcode 15 introduced String Catalogs, an evolution that provides richer metadata, better tooling, and improved support for different pluralization rules. Both methods are solid for managing localized content during development and build time.

However, the core limitation of these default mechanisms is their static nature. The strings are bundled with the app, meaning they cannot be altered once the app is shipped to users. While iOS allows users to change their device language, and apps can respond to `Bundle.main.preferredLocalizations` to load different compiled language bundles, the content within those bundles remains fixed. This static approach prevents dynamic content updates and real time localization adjustments without a full app release.

Patterns for implementing remote strings in iOS

To overcome the limitations of static localization, you can implement remote string capabilities using a few common patterns. One approach involves building a custom API and caching layer. This entails setting up your own backend server to host text content, fetching JSON data from this server within your app, parsing it, and then storing it locally using mechanisms like `UserDefaults` or Core Data. You would also need a fallback strategy to display local strings if the remote fetch fails or if there is no network connection. The challenges with this method include developing and maintaining the backend, managing translations across multiple languages, and implementing real time updates and an efficient caching strategy.

A more specialized and often simpler alternative is to use a dedicated content service. These services are designed specifically for managing app UI content and come with a suite of tools that simplify the entire process. They typically offer a web dashboard for defining text keys, built in translation features, and SDKs for various platforms, including iOS. Such services handle the complexities of content delivery, real time updates, and caching, allowing your team to focus on content creation rather than infrastructure. CMSCure is an example of such a service, providing a simplified way to manage and deliver remote strings to your iOS applications.

Integrating remote strings with SwiftUI

SwiftUI's declarative nature makes it well suited for integrating dynamic content. To use remote strings, you would typically fetch them through an `ObservableObject` or an `EnvironmentObject` that holds your localized content. This object would be responsible for retrieving the strings from your remote source and notifying your views when the content changes.

When a string is updated remotely or the app's language is switched at runtime, your `ObservableObject` would publish these changes. SwiftUI views observing this object would then automatically re render, displaying the new text. For example, a `Text` view could display `Text(viewModel.remoteString(forKey: "welcome_message"))`, where `remoteString` is a method that retrieves the current value for a given key from your content provider. This pattern ensures that your UI remains responsive and up to date with the latest content.

Integrating remote strings with UIKit

For UIKit based applications, integrating remote strings involves updating UI components like `UILabel`, `UITextView`, or `UIButton` titles dynamically. You would typically have a singleton or a dedicated manager class responsible for fetching and storing the remote strings. When content updates or the app's language changes, this manager would notify relevant UI controllers or views.

You can use `NotificationCenter` or Key Value Observing (KVO) to listen for content updates. For instance, after fetching new strings, your manager could post a notification, and your view controllers would observe this notification to update their labels: `myLabel.text = remoteStringProvider.string(forKey: "greeting")`. This ensures that even in UIKit's imperative style, your application can react to dynamic content changes and maintain a consistent user experience across different languages and content versions.

Introducing CMSCure for remote iOS strings

CMSCure is a hosted content service specifically designed for managing app UI content, including text, colors, and images. It provides a web dashboard where teams can define keys for their UI text, translate them into multiple languages using built in AI translation, and then publish these changes. The CMSCure iOS SDK, available via Swift Package Manager, integrates into your Swift, SwiftUI, and UIKit projects.

Once integrated, the SDK fetches the content you have defined and published. Crucially, it receives live updates over WebSockets whenever you publish new content from the CMSCure dashboard. This means that copy, translations, colors, and images can change in your shipped app without requiring a new release or an App Store review. When you use a string managed by CMSCure, for example, a `CureString` representing a key like "app_title", its value will automatically reflect the latest published content, ensuring your app is always current.

How CMSCure handles runtime language switching

A key advantage of using a service like CMSCure is its support for runtime language switching. This feature allows your users to change the application's language directly within the app, independent of their device's system language settings. This is particularly useful for multilingual users or for apps that cater to diverse audiences.

The CMSCure iOS SDK can be configured to fetch content for a specific locale. When a user selects a different language within your app, you instruct the SDK to load the content for that new locale. Upon publishing new content or switching languages, the UI updates automatically, either through the real time push over WebSockets or by explicitly re fetching the content. This capability significantly enhances the localization experience, providing flexibility and immediate content delivery for any supported language.

When a full headless CMS might be a better fit

While CMSCure excels at managing app UI content like text, colors, images, and structured data stores, it is important to understand its scope. CMSCure is UI first and is not designed as a full headless CMS with extensive page modeling capabilities. This means it does not offer visual page builders, GraphQL APIs, public write or management APIs for SDKs (SDK access is read only), or complex content workflows with review and approval states.

If your project requires advanced content modeling, the ability to build and manage entire web pages, multiple preview environments, or deep integrations with various third party services, a full headless CMS like Contentful or Strapi might be a more suitable choice. CMSCure focuses on providing a simplified solution for dynamic UI content, ensuring agility for text, color, and image updates without the overhead of a comprehensive content management system.

Frequently asked questions