Match App Store Captions to Your Localized App [2026]

To keep a localized App Store screenshot caption from failing review, translate it against your app's own localized interface strings, not against the English caption in isolation. When a caption names a feature by a word your localized app never uses, the screenshot and the app disagree, and that mismatch, not a clumsy translation, is what trips App Store Review Guideline 2.3 [1].

Below is the workflow no localization guide spells out: where your real localized strings live on iOS and Android, how to pull the handful that matter into a short caption termbase, and the per-locale check that catches drift before you submit.

TL;DR:

• The rejection trigger is term drift, not mistranslation. Your captions and your in-app interface usually get localized by two different processes, so they disagree on the same feature's name.
• Your app's authoritative localized words live in a String Catalog (a .xcstrings file) on iOS [2] and in res/values-<locale>/strings.xml on Android [3]. Translate captions against those, not the English caption.
• Build a small caption termbase (10 to 20 feature nouns and button verbs) from those files, so every caption reuses the exact word the app already shows.
• Guideline 2.3 requires screenshots to "accurately reflect the app's core experience" [1], so a caption promising a feature the localized app doesn't name is the exact mismatch review is built to catch.

Table of contents

• Why do localized captions fail review even when the translation is correct?
• Where do your app's real localized strings live?
• How do you build a caption termbase from your app's strings?
• What causes term drift between captions and your UI?
• How do you QA localized captions before you submit?
• Ship captions that speak the app's language

Why do localized captions fail review even when the translation is correct?

Because App Review checks whether your screenshots match the app, not whether your German is grammatical. A caption can be a flawless translation of your English source and still name a feature by a term your localized app never uses. That disagreement between the caption and the interface is the failure, and it lands on Guideline 2.3.

Here's the shape of it. Your English caption says "Instant transfer." A translation API renders the German as "Sofortüberweisung," which is correct German. But your app's German interface labels that same button "Direktzahlung," because whoever localized the app chose a different valid word months ago. The caption and the app now promise the feature under two different names. Apple's rule is explicit: "make sure all your app metadata, including privacy information, your app description, screenshots, and previews accurately reflect the app's core experience" [1]. Guideline 2.3.1(a) sharpens the stakes, calling out "marketing your app in a misleading way, such as by promoting content or services that it does not actually offer" as "grounds for removal" [1]. A caption naming a feature the localized app doesn't name under that word is precisely that kind of mismatch.

This is a different problem from matching your ranking keywords. Aligning captions with your title, subtitle, and keyword field is a visibility play, covered in the screenshot keyword strategy guide. Matching captions to your app's own UI strings is an accuracy play, and it's the one that gets you rejected. For the full rundown of the six ways caption translation breaks, start with the caption translation mistakes breakdown; this post goes deep on the single most expensive one. If the term screenshot localization is new to you, that's the definitional overview.

[VISUAL: Two-panel annotated comparison of one German screenshot frame. Left panel labeled "Drift": caption reads "Sofortüberweisung" with an arrow pointing to the app's UI button below it reading "Direktzahlung", the two words circled in red to show the mismatch. Right panel labeled "Matched": caption reads "Direktzahlung" matching the same UI button, circled in green. Caption under the figure: term drift is a caption-vs-app disagreement, not a grammar error.]

Where do your app's real localized strings live?

Your authoritative localized words live in your app's string resources, not in your marketing copy. On iOS that's a String Catalog, a .xcstrings file that Apple describes as containing "an entire string table in a single file," including "all translations and extra metadata for each localizable string in that table" [2]. On Android it's a strings.xml file per locale. Those files, not the English caption, are the source of truth for a caption's terminology.

On iOS, the String Catalog holds every string that "will be presented to the user at runtime, and therefore needs to be translated into all of the languages your app supports" [2]. It's the modern format that will "supersede both strings and stringsdict files in Xcode" [2], so on a current project the button labels and feature names your users actually read are sitting in Localizable.xcstrings. To hand those to a translator or pull them for reference, Xcode exports localizations as XLIFF, an editable file per language that round-trips back into the catalog.

On Android, the same words live in resource files keyed by locale:

• Default strings: res/values/strings.xml, the fallback for every unsupported locale.
• Locale-specific strings: res/values-<language-qualifier>/strings.xml, for example res/values-fr/strings.xml for French or res/values-ja/strings.xml for Japanese [3].
• Runtime selection: "When a user runs the app, Android automatically selects and loads the resources that best match the device" [3], so res/values-de/strings.xml is exactly what a German user sees on that payment button.

Whichever platform you ship, the point is the same. There's a file that already decided what your app calls each feature in each language. That file wins, and your caption has to agree with it.

How do you build a caption termbase from your app's strings?

Pull the 10 to 20 words that carry the meaning in your captions, the feature nouns and the call-to-action verbs, and lock each to the exact localized string your app already uses. That short list is your caption termbase. Every localized caption then reuses those terms verbatim, so the words on the screenshot always match the words in the app.

The workflow is four steps, and it's mechanical once you've done it once:

1. List your caption vocabulary. Across your 10 frames, which feature names and button verbs actually appear? Most apps have a small set: the two or three headline features, the primary CTA ("Start," "Try free," "Upgrade"), and the category noun ("workout," "budget," "transfer").
2. Find each term in the app's localized strings. Open the target locale's .xcstrings (or strings.xml) and search for the English source term. Record the exact localized string the app ships.
3. Write the pairs into a per-locale table. One row per concept, one column per language. This is the artifact the caption writer works from.
4. Localize captions against the table, not against a raw API. The translator or native speaker still transcreates the hook for tone, but the load-bearing feature words are pinned to what the app says.

A caption termbase for a payments app's German set might start like this:

The table above is illustrative, not a translation you should copy: pull your own rows from your own string files. The discipline is what matters. Ten rows take an afternoon to build and turn "did the caption use the right word?" from a judgment call into a lookup.

What causes term drift between captions and your UI?

Two translators and no shared glossary. Your in-app strings usually get localized by a developer's translator or a string-file service, while the caption copy gets run through a different tool, often machine translation, weeks later. Nothing forces the two to pick the same word for the same feature, so they drift apart, and the screenshot is where the gap becomes visible.

Four things pull them apart in practice:

• Synonyms in the target language. German has more than one valid word for "payment"; French has several for "share." Two competent translators land on different ones, and both are correct in isolation.
• Machine translation picking the generic word. An API optimizes for the common term, while your app may use a specific or branded one. The caption reads fine and still doesn't match.
• UI strings that changed after the captions were rendered. You renamed a feature in a later build, updated strings.xml, and never re-rendered the localized screenshots. The caption now describes a button label that no longer exists.
• Register mismatch. The app's UI uses formal address, the caption uses casual, or the reverse. Same meaning, different voice, and it reads as two teams wrote them, because two teams did.

The fix for all four is the same: one termbase that both the app-localization and the caption-localization processes draw from. When the source of truth is shared, drift has nowhere to start.

How do you QA localized captions before you submit?

Diff the caption terms against the app's localized strings, one locale at a time, then preview the set in App Store Connect. Confirm three things per locale: every feature word on a caption appears in that locale's string file, a real localized screenshot set exists, and the interface captured inside the screenshot is running in the target language, not English.

Keep the check narrow and terminology-focused, because that's where the rejections hide:

• Term diff. Walk your termbase table against the finished captions. Every pinned word should appear exactly as the app's string file spells it. This is the step that catches drift before a reviewer does, and when it flags a word, re-rendering that locale's set from the corrected caption in a screenshot builder closes it in one turn.
• The primary-language fallback. If you added a language but skipped its screenshots, "screenshots and the properties for the new language default to those of the primary language" [4], so shoppers see your English frames under a translated title. Confirm a dedicated set exists per locale.
• The interface underneath. Guideline 2.3.3 says "Screenshots should show the app in use" [1], so the app captured inside the frame has to be running in that language too, not just the caption on top of it.

The full pre-submission sweep across all six caption pitfalls lives in the caption translation mistakes guide, and the broader metadata side sits in the complete localization guide. This QA pass is the terminology slice: does every word on the screenshot match the word in the app? Preview each localized set in App Store Connect before you submit, because that's the one place the fallback and the English-interface traps show up.

Ship captions that speak the app's language

Accurate localized captions come down to one rule: the word on the screenshot is the word in the app, in every language you ship. A short termbase pulled from your .xcstrings or strings.xml files turns that rule from a hope into a checklist, and it's the fix for the term drift that a plain translation pass leaves behind. The words your app already uses have earned the right to be on the screenshot; the caption's job is to agree with them.

The production bottleneck is re-rendering the set once you've fixed a term, which is why the discipline pays off most when the render step is cheap. A chat-based screenshot builder can swap a caption's wording across the localized set and re-render, so correcting a drifted word is another message, not another afternoon in a design tool. Get the terminology right against the app first, build the termbase once, and the corrected words carry across every frame on the next render.