Localize Numbers & Prices in App Store Screenshots [2026]

Translate a caption's words and leave "$4.99", "1,000,000 users", or "12/25/2026" untouched, and the frame reads half-finished to exactly the shopper it's meant to convert. Four format layers change between markets: digit shapes, separators and grouping, currency rendering, and date order. Prices are the special case, because Apple, not your design file, decides what each storefront charges [1].

Below: a per-axis reference table with the exact characters that flip between markets, three ways to handle prices without painting a number Apple's next price update will falsify, and a pre-submit numeric pass that takes minutes per locale.

TL;DR:

• Four axes change between locales: digit shapes, decimal and thousands separators, currency symbol and position, and date order. Same value, different string: 1,234.56 in the US is 1.234,56 in Germany and 1 234,56 in France [3].
• Same currency doesn't mean same format. A euro amount puts the symbol before the number in the Netherlands and after it in France, with different separators between them [3].
• Caption prices go stale on their own. You set one base price and Apple generates "prices across the other 174 storefronts and 43 currencies" [1], then updates them periodically. Pixels don't update.
• A wrong caption price is a compliance surface, not a typo. Guideline 2.3.1 names "promoting a false price" as grounds for removal [2].

Table of contents

• Why do unlocalized numbers undo a translated caption?
• Which four format axes change between locales?
• Should your captions show a price at all?
• How do you localize the number itself, not just the format?
• How do you run a numeric pass before you submit?
• Treat every caption number as copy

Why do unlocalized numbers undo a translated caption?

Because numbers are usually the proof layer of the caption. The stat, the price, the rating, the date: that's the part of the frame built to persuade rather than describe. When those render in a foreign format, the most load-bearing element on the screenshot is the one telling a local shopper the app wasn't made for them.

There's a review dimension too. Apple's Guideline 2.3 requires that your screenshots "accurately reflect the app's core experience" [2], and a caption number is metadata like any other caption word. Unlocalized numbers are one of the six ways translated captions break, and the caption translation mistakes guide maps all six. This post is the execution layer for the number problem specifically: which formats flip, why prices deserve their own rule, and how to check a set before you submit. If screenshot localization as a discipline is new to you, start with the definition.

Which four format axes change between locales?

Four: digit shapes (which characters represent 0 to 9), separators and grouping (what splits decimals from thousands, and how many digits per group), currency rendering (symbol, position, spacing), and date order (the sequence of day, month, and year). Every numeric element in a caption sits on at least one of these axes, and most sit on two.

None of this is folklore you have to memorize. The Unicode CLDR "supplies key information and structures critical for programs and operating systems around the world to ensure that they feel natural" [4], and it's "incorporated into all modern operating systems and browsers; into many programming languages such as Java, C#, .NET, Swift, Javascript" [4]. When your app displays a price or a date at runtime, the OS formatter pulls the right pattern from that data automatically.

Your caption doesn't. A caption is pixels, so whoever typed the number picked its format, and the formatter never got a say. That's the entire reason this layer needs a manual pass: the machinery that quietly localizes every number inside your app is bypassed by the text painted on top of it.

Two axes go deeper per market than a table can. Digit-shape decisions for Arabic-script locales (Eastern versus Western numerals, by region and app category) are worked through in the Arabic typography guide, and Japanese conventions (half-width digits, the 万 counter for large counts, currency position) in the Japan screenshot guide. For quick per-market defaults across the biggest storefronts, the market priority guide carries a reference list.

Should your captions show a price at all?

Only if you're prepared to re-render that locale's screenshots whenever the storefront price changes. A caption price is frozen pixels describing a number Apple adjusts over time, so it drifts toward wrong by default. If you won't maintain it, cut it, or replace it with price-free proof.

Here's the mechanism, and as of 2026 it's more automatic than most designers assume. In App Store Connect you set one base price, and Apple uses it as "the basis for automatically generating prices across the other 174 storefronts and 43 currencies" [1]. Generated prices "account for foreign exchange rates and certain taxes, and follow the most common pricing convention for each country or region" [1]. They also move: "Periodically, Apple updates prices in certain regions based on changes in taxes and foreign exchange rates" [1], though Apple "will never change the price in your base country or region" [1]. So the German price of your $4.99 app isn't $4.99 converted at today's rate. It's whatever Apple generated for that storefront, rounded to a local convention, and it can change without you shipping anything. The caption you painted last spring doesn't hear about any of it.

That drift has a name in the Review Guidelines. Guideline 2.3.1 calls out "promoting a false price, whether within or outside of the App Store" as "grounds for removal of your app from the App Store" [2]. If the number belongs to an in-app purchase, 2.3.2 adds that your "description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases" [2]. Read alongside 2.3's accuracy rule, a stale or wrong-market caption price isn't a cosmetic slip. It's a screenshot promising terms the store page below it contradicts.

Three workable positions:

• Cut the price from the caption. The store page already shows the real localized price one scroll below your screenshots, so most sets lose nothing by not repeating it. This is the zero-maintenance default.
• Show it and maintain it. Keep a per-locale note of which frames carry prices, and re-render when pricing changes. Manually managing storefront prices makes this steadier, since "If you select your own prices, Apple won't adjust your pricing on those storefronts in the future" [1]. Realistic for two or three markets, expensive across twenty.
• Make the proof price-free. "Try it free for 14 days", a rating, a user count, a result stat. Same persuasion job, no number that a pricing table can falsify.

How do you localize the number itself, not just the format?

Reformatting isn't converting. A caption promising "Save $200 a year" isn't localized by rewriting it as 200,00 €. The honest German figure is whatever your product actually saves a German user, in euros, rounded the way local copy rounds money. Format is the surface; magnitude, rounding, and truth are the number.

• Convert the magnitude, then round like a local. A dollar figure passed through an exchange rate lands on something like 183,42 €, which no marketer would write. Round to the figure a native ad would use, and keep it defensible.
• Check that the claim survives the market. If the savings math was built on US prices, the local math is different, because the local prices are different, including the ones Apple generated for your own app [1]. A proof number that's true in one storefront and false in another fails 2.3 in the second one [2].
• Render large counts in local units. "1,000,000 users" reads natively in the US and Germany once the separators are fixed, but a Japanese frame reads 100万 more naturally than a six-zero string, and Indian grouping shows ten million as 1,00,00,000 [3]. The Japan screenshot guide covers when to convert the unit versus keep the digits.
• Ambiguous dates are worse than foreign ones. 12/25/2026 in a German frame is at least visibly wrong (there's no month 25). 03/04/2026 is silently wrong: March to one reader, April to another. If a date has to appear, use the locale's order or spell the month.

Watch where these numbers live in your layouts. Stat-led compositions like the stats-hero layout put a single number at headline scale, which means a separator on the wrong axis isn't a footnote slip, it's the largest element on the frame.

How do you run a numeric pass before you submit?

Inventory every numeric element across the set, write the correct target form per locale for each, fix the source design, and re-render. A ten-frame set rarely carries more than a dozen distinct numbers, so once the reference row exists the pass runs in minutes per locale.

1. List the numbers. Walk every frame and collect prices, stats, ratings, dates, percentages, and units into one row per value. This inventory is reusable for every future locale.
2. Write the target form per locale. The best reference isn't a table on the internet, it's your own app. Run the localized build and read how it renders the same value: the OS formatter already applied that locale's CLDR patterns [4], and a caption painted over the app should agree with the app. This is the numeric version of matching caption words to your localized UI strings.
3. Fix the source design, not the export. Correct the caption text in the design that generates the set, so the fix carries into every future render instead of dying in one PNG.
4. Re-render and preview per storefront. A chat-based screenshot builder can apply the corrected formats across a locale's whole set and re-render it in one turn, which is what makes numeric passes sustainable past your second or third market. Then preview each localized set in App Store Connect, because a wrong-format number that survived your design tool is still visible there before a shopper or a reviewer sees it.

Treat every caption number as copy

Words get translators. Numbers inside your app get formatters. Caption numbers get neither unless you run the pass, because they're pixels that both pipelines skip. The four axes tell you what to check, the price rules tell you what not to promise, and the pre-submit pass catches what slipped through.

The other five ways translated captions break, from term drift to the primary-language fallback, are mapped in the caption translation mistakes guide. And when a numeric pass flags half a set, correcting the format and re-rendering those frames in the screenshot builder is a message, not a rebuild: get the numbers right once, and let the render carry them across every frame.