Your submission passes in English but gets rejected for Japanese, with the reviewer citing a claim in the JA subtitle that doesn’t appear anywhere else; or your Spanish screenshots show a feature that was removed three releases ago because the localization team never got the latest mockups; or some locales still display the base English fields because the translations were never confirmed. App Store Connect reviews each locale as its own listing, so a single bad translated string can hold the whole version in Rejected.
Fastest fix: the most common rejection is an extra marketing claim added to one locale’s subtitle or description that the base language never made (cause #1 below). Find that locale, edit the field so it is a faithful translation of the base, and resubmit. If you did not change the binary, this is a metadata-only resubmission — no new build, no waiting in the build-processing queue.
Apple cites this under App Review Guideline 2.3.7 (metadata must accurately reflect the app and not include irrelevant or misleading claims). Do not confuse it with 2.3.8, which is about metadata being appropriate for a 4+ audience (icons, screenshots, previews); that is a different rejection. As of June 2026, localization is treated as a trust problem, not just an ASO lever — one stale translated claim can trigger rounds of back-and-forth even when your base language is clean.
The fix is one part audit (find every locale that diverges from the canonical base language) and one part workflow change (stop letting localization happen out-of-band from product).
Which bucket are you in
| Symptom in the rejection / listing | Most likely cause | Build needed? |
|---|---|---|
| Reviewer quotes a claim in one locale that isn’t in the base | #1 extra claim | No (metadata only) |
| Screenshot shows old UI / a removed feature | #2 stale screenshots | No |
| A locale’s page shows English text | #3 untranslated locale | No |
| Custom Product Page contradicts the main locale page | #4 CPP overlap | No |
| Keyword field has English tokens or a competitor name | #5 keyword field | No |
| App falls back to English when device is set to that locale | #6 in-app strings missing | Yes (new build) |
Common causes
Ordered by hit rate. Number 1 is by far the most common.
1. Localized titles or subtitles added claims to win search rank
Marketing or a regional team added “#1 AI productivity app” or “with built-in voice assistant” to the Japanese subtitle for ASO. The base language never made that claim. A locale reviewer flags it because the app doesn’t deliver that capability for them.
How to spot it: The name and subtitle live under App Store Connect → (your app) → App Information (shared across versions); the description, keywords, promotional text, and “What’s New” live under the specific version page in the left sidebar (for example 1.0 Prepare for Submission or the in-review version). In each place, switch the language pop-up across every offered locale and copy the fields into a spreadsheet. Diff each row against the base language. Any noun, verb, or numeric claim that exists in only one locale is a candidate.
2. Localized screenshots show stale UI or absent features
The localization team got a screenshot template six months ago, swapped text overlays, and shipped. The underlying UI screenshot is from build 1.4; you’re now on 2.7. Buttons that moved, features removed, dark-mode style changes — all visible only in the localized listing.
How to spot it: Pull each locale’s screenshot set from App Store Connect (right-click → Save). Run them through exiftool or just visually diff against your latest dev-build captures. Anything that looks “older” than the current build is stale.
3. A locale was added but localized fields never got reviewed
You enabled French in App Store Connect for distribution, but the localized title still says the base English text because nobody set it. Reviewer sees a French App Store page showing English copy and flags it as low quality.
How to spot it: For each locale, check whether the title and description match the base language verbatim. If yes, either you forgot to translate or the field defaults to base because no override was set.
4. Custom Product Pages or Variant Pages overlap with locale listings
You set up a Custom Product Page for an ad campaign targeting Germany, but the page’s screenshots use US-localized text. The German user lands on a “Custom” page that visually contradicts the main German listing.
How to spot it: App Store Connect → Custom Product Pages → for each, check which locales it applies to. Open the page in a German storefront on a real device. Compare with the main German listing.
5. Keyword field mixes locales or contains banned terms in a region
The keyword field is per-locale and capped at 100 characters (comma-separated, no spaces between terms — spaces waste characters). Some teams paste English keywords into the Japanese field, or use competitor names that are trademarked in one country but not another. A locale-specific reviewer catches it.
How to spot it: Check which storefronts you ship to under App Store Connect → (your app) → Pricing and Availability. Then open the version page and read the Keywords field for each locale (keywords are version-specific, not under App Information). Any locale whose keyword field contains untranslated English tokens, a competitor’s brand name, or terms duplicated from the name/subtitle is risky.
6. The app’s in-app locale doesn’t match the App Store locale offered
You list French as a supported language on the App Store page but the app falls back to English when set to fr-FR. Reviewer notices the mismatch and flags 2.3.7 (Metadata Accuracy).
How to spot it: Run the app on a simulator set to French. If any user-facing string is still English, the App Store listing is over-promising what the build delivers.
Before you start
- Confirm whether the rejection targets one locale or all of them. The Resolution Center message differs by locale.
- Lock the base language (usually English U.S.) as canonical. Every other locale aligns to it.
- Decide up front whether a metadata-only resubmission is enough, or whether you also need a new build (only cause #6 needs one).
- Screenshot every locale’s current fields before you edit. App Store Connect does not keep a version history of metadata.
Information to collect
- The reviewer’s rejection text plus the locale(s) it applies to.
- A spreadsheet of all locale fields: title, subtitle, description, keywords, promo text, screenshots.
- The base-language version of each field as the ground truth.
- Localized screenshot files (download from App Store Connect).
- A list of Custom Product Pages and Variant Pages with their applicable locales.
Shortest path to fix
Step 1: Build the locale matrix
Use App Store Connect’s API or just the web UI to extract every localized field:
# App Store Connect API: list all localizations for a version
curl -H "Authorization: Bearer $JWT" \
"https://api.appstoreconnect.apple.com/v1/appStoreVersions/$VERSION_ID/appStoreVersionLocalizations" \
| jq '.data[] | {locale: .attributes.locale, description: .attributes.description, keywords: .attributes.keywords, promotionalText: .attributes.promotionalText, whatsNew: .attributes.whatsNew}'The version-scoped resource (appStoreVersionLocalizations) holds description, keywords, promotionalText, whatsNew, marketingUrl, and supportUrl. The name and subtitle live on the separate appInfoLocalizations resource because they are shared across versions — query that too if you need them. Note: the API has no bulk-update endpoint, so a fix is one PATCH /v1/appStoreVersionLocalizations/$LOCALIZATION_ID per locale.
Dump everything into a CSV. Each row is a locale; columns are name, subtitle, description, keywords, promo text. The base language is row 1.
Step 2: Diff each locale against the base
Walk the spreadsheet locale by locale. For each cell, ask:
- Does it contain a noun, verb, or claim absent in the base? Flag for removal.
- Does it contain a numeric claim (“#1,” “Best of 2026”) not in the base? Flag.
- Is it identical to the base (untranslated)? Flag for translation.
- Does it mention a competitor’s brand? Flag for removal.
Step 3: Re-capture localized screenshots from the actual localized build
In Xcode, set the simulator to each target locale (Edit Scheme → Run → Options → App Language), launch your build, and capture the canonical screen set. Do not edit base-language screenshots in Photoshop to add localized text — capture from the real localized run.
For automation:
# fastlane snapshot with per-locale Snapfile
fastlane snapshot --languages "ja-JP,fr-FR,es-ES,zh-Hans"Step 4: Reconcile each locale’s listing fields
On the version page in App Store Connect, switch the language pop-up and edit each locale’s fields, then click Save, so that:
- The set of claims is a translation (not an extension) of the base language.
- The keyword field uses locale-appropriate tokens, no competitor names, no words duplicated from the name or subtitle (Apple treats name + subtitle + keywords as one combined index).
- Screenshots are from the locale-actual build at the current version.
Name and subtitle are edited separately under App Information because they are shared across versions.
Step 5: Verify Custom Product Pages and Variant Pages
For each Custom Product Page or Variant, check the screenshots and text against the same canonical claim set. Variants are reviewed alongside the main listing; inconsistency triggers rejection.
Step 6: Resubmit (metadata-only if binary unchanged)
If the rejection only touched locale fields, you do not need a new build. While the version is still in the rejected state you can edit the metadata in place and click Submit for Review again (or Add for Review then submit) — App Store Connect lets you re-submit the same build with corrected metadata. Add a short note in Resolution Center saying exactly what you changed in which locales. Only if you had to add missing in-app localization strings (cause #6) do you archive a new build first, because that changes the binary.
How to confirm the fix
- The locale matrix spreadsheet has zero flags after the audit pass.
- Each locale’s screenshots are dated within the current release window.
- A native speaker of each locale reads the listing and confirms it describes the app accurately.
- The locale that triggered rejection moves to Waiting for Review after resubmission.
If it still fails
- Reply in Resolution Center with the locale matrix attached, showing the before/after of the flagged claim.
- Ask for clarification on which exact word or screen the reviewer flagged; some 2.3.7 rejections are vague.
- Temporarily disable the problematic locale via Pricing and Availability so the rest of the listing can ship; re-enable after fixing.
- Engage Apple Developer Relations if a locale-specific reviewer is consistently citing claims that exist in the base language too.
Prevention
- Treat localization as part of the release branch, not a parallel track; require translated metadata as a pre-merge check.
- Use
fastlane deliveror the App Store Connect API to push localized fields from a single canonical source file in your repo (e.g.,app-store/metadata/<locale>.txt). - Pair every translator with a screenshot reviewer who runs the actual localized build, not just text strings.
- Add a release-checklist item to capture or re-capture localized screenshots from the current build for every locale.
- Avoid locale-only marketing claims for SEO gain. The short-term ranking lift is dwarfed by submission churn when reviewers flag them.
FAQ
Do I need a new build to fix a localization rejection? Usually no. If only the App Store listing text or screenshots are wrong (causes #1 through #5), edit the metadata and resubmit the same build. You only need a new build for cause #6, where the app itself is missing the in-app localized strings it claims to support.
Why did only one language get rejected when the others passed? App Store Connect reviews each locale as an independent listing. A claim, screenshot, or keyword that exists only in the Japanese fields is invisible to the reviewer looking at the English page, so the base language can be perfectly clean while one locale fails 2.3.7.
Is this a 2.3.7 or a 2.3.8 problem? A divergent or inaccurate translated claim is 2.3.7 (metadata accuracy). 2.3.8 is a separate rejection about metadata being suitable for a 4+ audience (icons, screenshots, previews). Read the Resolution Center message for the exact clause cited.
Can I just remove the failing language to ship faster? Yes, as a stopgap. Toggle the locale off under Pricing and Availability so the rest of the listing can go live, fix the fields, then re-enable it. It is a workaround, not a fix.
How long does a metadata-only resubmission take to review? As of June 2026 most reviews complete within roughly a day, often faster for a metadata-only change since there is no build to process. There is no separate fast lane for metadata fixes; you can request an Expedited Review only for genuinely urgent cases.
The reviewer flagged a claim that also exists in my base English. Now what? That is usually a reviewer error or an ambiguous claim. Reply in Resolution Center with the locale matrix showing the same claim in the base language, ask which exact word or screen was flagged, and if it recurs, escalate through Apple Developer Relations / the Contact Us form.
Related reading
- Screenshot / metadata issue during submission
- App rejected for misleading claims
- App Review Guideline 2.1 — more info needed
- App version waiting for review
- App Review Guidelines 2.3 — Accurate Metadata (official Apple Developer site)
Tags: #Troubleshooting #App Store #App review #Metadata #Localization