I'm trying to change an app's Primary Language in App Store Connect from de-DE to nl-NL and hitting a state I can't resolve through any interface available to me. Environment App Store Connect (web UI) and App Store Connect API v1 Problem UI: App Information → Primary Language → nl-NL → Save fails with: "Primary Locale couldn't be saved because you must first provide all the required screenshots for each version in this language." API: PATCH /v1/apps/1669670490 with attributes.primaryLocale = "nl-NL" returns HTTP 409: ENTITY_ERROR.ATTRIBUTE.INVALID.INVALID_STATE.MISSING_SCREENSHOTS_PRIMARY_LOCALE Error detail contains an unsubstituted placeholder: "...you must first provide all the required @@LANGUAGE_VALUE@@ screenshots..." What I've verified Current live version (3.7.6) and current editable version (3.7.11) both have complete nl-NL screenshot sets for all required device sizes (6.9" iPhone, 13" iPad). No Watch app, iMessage extension, Custom Product Pages, In-App Events, or IAPs. Enumerated all 23 versions via the API (1.0 → 4.1.0). 19 of them have an nl-NL appStoreVersionLocalization (with real historical description/keywords/support URL) but zero nl-NL screenshots attached. Tried POSTing an nl-NL screenshot set to one historical version (4.1.0) directly via the API to confirm this isn't just a UI restriction. Also returns 409 ENTITY_ERROR.ATTRIBUTE.INVALID.INVALID_STATE — historical versions are locked against edits (including screenshots) at the API level, not just the UI. Question Since these historical versions can't be edited through any supported interface, is there a documented way to satisfy or bypass the "screenshots for each version" check for locked historical versions when changing Primary Locale? Filed as case 20000130035264 with Developer Support, who pointed me here for the technical side.

I have an app with a Widget Extension. Both the main app and the widget extension link against the same Swift Package, which contains a localization bundle (String Catalog) used by SwiftUI views inside the package. To make the package's views follow the app's configured language (rather than the system language), I set CFBundleAllowMixedLocalizations to NO in the Info.plist of each target (main app and widget extension). Behavior in the main app: This works as expected. If the app only supports Korean, the package's views display Korean text even when the system language is set to English. Behavior in the widget: The same views (from the same package) display English instead of Korean, even though the widget extension has the identical CFBundleAllowMixedLocalizations = NO setting and the widget's view code lives entirely in the package — not in the widget extension target itself. Question: As far as I understand, widgets are supposed to follow the host app's language setting. Given that both targets have the same Info.plist configuration, why would the widget extension resolve localized strings differently from the main app for code in the same package? Is this expected behavior for widget extensions specifically, or a bug? Is there a recommended workaround to force a widget extension (and by extension, the Swift Package code it runs) to use the app's language instead of the system language?

Hello, I'm experiencing an issue with App Store Connect localization for my iOS app. Despite configuring the primary language as French and completing all localizable metadata in French (name, description, keywords, screenshots, etc.), the app is displaying in English on the App Store public listing. Current setup: Primary Language: French ✓ All mandatory fields filled in French ✓ App approved and published ✓ The issue: When users in France access the App Store, they see the app listed with language tag "EN" instead of "FR", even though all content is in French in App Store Connect. What I've tried: Verified primary language setting (already set to French) Checked all visible metadata (all in French) Waited 24h for sync/cache update Re-submitted the app Has anyone experienced similar behavior? Is there a specific requirement or setting I might be missing that affects how App Store determines the display language? Note: I suspect one optional field (promotional text) might be empty in the localization section, but I would expect the system to either fill it with primary language content or display a warning rather than reverting to English. Thanks for any insight!

Since, Apple has long been recognized for its exceptional attention to typography. That is why I am surprised that Smart Punctuation in iOS does not respect national typographic conventions for quotation marks. For example, when writing in Czech, iOS automatically inserts English quotation marks (“…”) instead of the correct Czech form („…“), and there is currently no option to change this behavior. This may seem like a minor detail, but smartphones have become the primary writing tool for millions of people. As a result, the default option of the software does more than automate typing — it shapes writing habits. Or Even more, most users start assuming that automatically inserted punctuation is correct for their language. When iOS consistently uses English quotation marks in Czech text, it unintentionally contributes to the gradual disappearance of Czech typographic conventions. Even professionals often leave the default quotation marks unchanged because correcting them manually in everyday writing is impractical and slows down their writting. Typography is part of every language’s cultural identity. Localization should therefore include not only translated interfaces, but also language-specific typographic standards. Therefore, I would like to suggest that iOS should automatically use quotation marks according to the active keyboard language (or provide a setting to choose the quotation mark style). Czech users would receive „…“, French users « … », German users „…“ or »…« according to regional conventions, and so on. This small change would improve localization, respect linguistic diversity, history, and help preserve national typographic traditions. With the current implementation, Apple unintentionally contributes not only to the widespread use of incorrect writing, but also to the gradual erosion of national typographic traditions and language-specific writing conventions. Daniel

Hello, I filed FB23906760 requesting full Persian (fa-IR) system-language support across Apple platforms. A focused Swift/SwiftUI feasibility and QA sample is attached privately to that feedback report. Apple platforms already provide important building blocks for Persian, including Persian text input, Unicode rendering, locale-aware formatting, semantic right-to-left layout support, and Persian calendar APIs. However, Persian is not currently selectable as a complete system interface language on iOS, iPadOS, or macOS. The submitted app-level sample exercises: runtime RTL/LTR layout switching; canonical Persian Kaf (U+06A9) and Yeh (U+06CC); ZWNJ (U+200C) preservation; LRI/PDI isolation for mixed Persian and Latin content; Persian digits and numeric separators; Foundation Persian-calendar conversion and month names; English/Persian localization-key parity; and localized accessibility metadata. I want to clearly distinguish application localization from operating-system support: A Swift or SwiftUI app can provide its own Persian strings through String Catalogs or localized resources. SwiftUI and Foundation provide useful primitives for app-level Persian support and repeatable QA. An app or sample project cannot add Persian to the system-language selector, translate Apple system UI or first-party apps, or add Persian to Siri, Dictation, Translate, or other system services. Those capabilities require implementation and release by Apple. The submitted project is therefore reproducible feasibility evidence and a QA seed, not a patch to Apple-owned operating-system resources. Its Persian copy is an AI-assisted engineering draft and is explicitly marked as requiring native linguistic, terminology, accessibility, and in-context review. I would appreciate guidance from Apple engineers on the following: What is the recommended configuration for testing a fully Persian-localized SwiftUI app when Persian is not available as a system UI language? Are there documented best practices for testing fa-IR RTL behavior, bidirectional text, VoiceOver metadata, Persian numerals, and Persian-calendar formatting consistently across iOS, iPadOS, and macOS? Are there additional developer-specific Feedback Assistant categories that would help Apple evaluate missing Persian support in system services and developer-facing localization infrastructure? Would additional fixtures or platform-specific targets be useful as supplements to FB23906760? More specifically, is there an Apple-recommended way to provide additional technical fixtures, terminology data, or validation cases to the relevant internationalization teams for evaluation of Persian (fa-IR) system-language support? This is an enhancement request and a technical localization question, not a request for information about unannounced product plans. Thank you.

Xcode 26.5 stucks on Localization Generating Comments: Running on macOS Tahoe 26.5 When this happens, Xcode does not add new keys, although enabled: The only (known) workaround is to restart Xcode. Same happened with Xcode 26.4, 26.4.1 on macOS 26.4.1.

Hello everyone, I am encountering an inconsistent typography behavior when developing for WidgetKit. Specifically, there is no native serif font fallback for Chinese characters (CJK) in the Widget environment, whereas Latin characters are fully supported. When using the .serif design modifier in SwiftUI: Text("Hello 世界").font(.system(size: 16, design: .serif)) English/Latin characters ("Hello"): System correctly renders using the pre-installed serif font (New York). Chinese characters ("世界"): System ignores the .serif design and falls back to the default sans-serif font (PingFang SC). Can I find any pre-installed native serif font for CJK in iOS that I can reliably invoke within my Widget Extension without bundling .ttf files? If not, do you have plans to map Font.design(.serif) to a pre-installed CJK serif font in future iOS releases so I can maintain design consistency across my localized widgets? Thank you for any insights or recommended workarounds.

Hi Apple Team, I am writing to formally request that Bangladesh be officially added to the supported country and region list. Bangladesh has a huge number of iPhone, iPad, and Mac users. However, because our country is not officially supported, users are forced to use fake locations just to set up their devices. Furthermore, because of this problem, users cannot even use a proper, local payment system to make purchases. This creates a frustrating experience for a massive and growing user base. Expanding official support to Bangladesh would allow users to accurately set up their Apple IDs, make secure purchases using local payment methods, and fully and safely participate in the Apple ecosystem. We hope Apple considers bringing official support to Bangladesh in the near future. Thank you!

Context is Swift UI iOS app with Xcode 26.6 In my project's Localizable.xcstrings, I have terms flagged as "don't translate". However, when I export the terms with the "Export localizations" menu command, these entry are still listed in the exported XLIFF files (with shouldTranslate:false) Any way to bypass these entries to get accurate clean XLIFF exports ? Thx&rgds, François

I have to use the user preferred language (the first, here French). In didFinishLaunchingWithOptions, I select the first in the array of languages. print(#function, Locale.preferredLanguages) let prefLanguage = Locale.preferredLanguages.count > 0 ? Locale.preferredLanguages[0] : "en" So I expect to get Français. That works OK in iOS 16 (both on device and simulator) as well as on iPad iOS 26, but not on iOS 26.1 simulator. log for iOS 16 simulator or on devices: application(_:didFinishLaunchingWithOptions:) ["fr-FR", "en-FR", "es-FR", "it-FR", "de-FR", "el-FR"] log for iOS 26 (Xcode 26.3) application(_:didFinishLaunchingWithOptions:) ["en-FR", "fr-FR", "es-FR", "de-FR", "it-FR", "el-FR"] Order is changed. Is this a known bug or am I missing something ?

Hello developers, I have a tricky question, that I do not understand. I have an application like this: https://apps.apple.com/cz/app/ignaci%C3%A1nsk%C3%BD-examen/id1589449136 that is in czech language. We have also the same application for e.g. italian: https://apps.apple.com/it/app/examen-ignaziano/id1589449136 or french: https://apps.apple.com/fr/app/examen-ignatien/id1589449136 that are valied and have proper screens and descriptions But the other languages have wrong pages, like: https://apps.apple.com/hr/app/ignaci%C3%A1nsk%C3%BD-examen/id1589449136 that should be in Croatia or https://apps.apple.com/pl/app/ignaci%C3%A1nsk%C3%BD-examen/id1589449136 that should be in Polish. Unfortunatelly, they are still in Czech language. I have in my Xcode and In AppStore are also several language mutations. Can you please help me what is wrong?

I have a Capacitor (web-based) iOS app. All UI strings are localized in the JavaScript layer at runtime, so the app bundle has no per-language storyboard or .strings resources. I want the App Store product page's "Languages" section to list every language we support (en, de, es, fr, it, pt-BR, tr) — right now it only shows English. In our last release I added a CFBundleLocalizations array to Info.plist with all 7 codes. That build is live, but the product page still shows only "English." My questions: Does the App Store "Languages" list derive from CFBundleLocalizations, from the actual .lproj folders compiled into the binary, or both? If .lproj folders are required, is adding empty/stub .lproj folders (registered in the project's knownRegions) enough, or do they need real localized content? After a build with the correct setup goes live, how long until the list refreshes? Thanks — I want to confirm the correct approach before shipping the next build.

Hello, I’m implementing the AppIntents framework in my app. I want to translate the TypeDisplayRepresentation that is used in the Shortcuts app UI like in a DeleteIntent (see my feedback about this: FB23451186 for more context). In the “Accelerating app interactions with App Intents” sample code we can see that this is done using a .stringsdict file, as follows for the “Trail” key (singular and plural): <key>Trail</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@VARIABLE@</string> <key>VARIABLE</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>Trail</string> <key>other</key> <string>Trails</string> </dict> </dict> I want to use a String catalog instead of a .stringsdict file because all my strings are in a String catalog. I tried to migrate the AppIntents.stringsdict file manually but it failed with an error: “An error occurred when migrating AppIntentsSampleApp/Resources/AppIntents.stringsdict: This stringsdict cannot be migrated: Missing required key 'NSStringFormatValueTypeKey' inside 'Trail' -> 'VARIABLE’” So I manually added a NSStringFormatValueTypeKey like this in the .stringsdict file: <key>Trail</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@VARIABLE@</string> <key>VARIABLE</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>NSStringFormatValueTypeKey</key> <string>lld</string> <key>one</key> <string>Trail</string> <key>other</key> <string>Trails</string> </dict> </dict> And then I’ve been able to migrate the .stringsdict file into a String catalog. The string catalog looks like this after migration: "Trail" : { "extractionState" : "stale", "localizations" : { "en" : { "stringUnit" : { "state" : "translated", "value" : "%#@VARIABLE@" }, "substitutions" : { "VARIABLE" : { "formatSpecifier" : "lld", "variations" : { "plural" : { "one" : { "stringUnit" : { "state" : "translated", "value" : "Trail (Catalog)" } }, "other" : { "stringUnit" : { "state" : "translated", "value" : "Trails (Catalog)" } } } } } } } } This works, which is nice. But I tried to reproduce the same result by having a %#@VARIABLE@ in my LocalizedStringResource defaultValue like this: TypeDisplayRepresentation( name: LocalizedStringResource( "Flower", defaultValue: "%#@VARIABLE@", table: "AppIntents" ), numericFormat: LocalizedStringResource( "\(placeholder: .int) flower", table: "AppIntents" ) ) But the String catalog doesn’t support that apparently, I can’t get a “substitution” object in my catalog, so I have to manually do it using the source code which is not ideal and painful. Is there a way to support this kind of substitution with no actual plural token in the string as we can see for the %#@VARIABLE@ for Trail? Thank you, Regards, Axel

Hey everyone I’m new here. I designed my app in 5 languages and I updated each one description, promotional, what’s new etc one by one step by step then submitted a new build but my app still says English under languages. I did everything by the book. If anyone has any advice or can check the Apple Store Chinese, Spanis, Japanese, Portuguese country app stores and look for my app golden edge ai and atleast confirm it’s showing up in those locales I would be eternally grateful! 🙏 🙏 https://apps.apple.com/us/app/golden-edge-gold-ai/id6774464201

Hi everyone, I recently launched my app, when searching for the app on Google, the official App Store link that appears in the search results is from the Chinese App Store. My app's primary language is correctly configured in App Store Connect, and I would naturally expect the search result to display in that primary language, or at least default to English. Has anyone else experienced this issue where Google indexes the wrong regional App Store page (e.g., pulling a Chinese localization instead of the global or primary one)? Is there a specific setting or metadata in App Store Connect I need to double-check to force the correct locale, or is this purely a Google crawling anomaly that usually resolves itself over time? Thanks in advance for any insights!

Hello Apple Keyboard / Internationalization team, I would like to ask about autocorrection and predictive text support for additional Cyrillic-based languages, especially Kazakh, Kyrgyz, Chuvash, and Ingush. These languages use Cyrillic scripts with their own letters, spelling rules, and word-frequency patterns. When users type in these languages, Russian-based autocorrection or missing language-specific correction can produce incorrect suggestions or replacements. My questions are: Are there plans to expand autocorrection and predictive text support for more Cyrillic-based languages? Is there a recommended way for developers or language communities to provide dictionaries, word-frequency lists, corpora, or other linguistic data to help improve autocorrection? Should this type of request be submitted through Feedback Assistant, Developer Forums, or another Apple channel? I have corpus-based frequency data and language resources for multiple Cyrillic-based languages and would be happy to share them if useful. Thank you. Ali Kuzhuget

Hello Apple Keyboard / Internationalization team, In the current beta, I noticed new keyboard support for Tuvan and Sakha. Thank you — this is very important for Cyrillic-based languages and their communities. I also noticed improvements to the Russian keyboard long-press options, but some Cyrillic letters used by other languages still seem to be missing. For example, Ossetian uses Ӕ ӕ, and this character does not appear as a long-press option. My questions are: Are there plans to expand the Russian keyboard long-press mappings to cover more Cyrillic-based languages? Is there a recommended way for language communities or developers to provide corpus/frequency data and character mappings to help improve keyboard support? Should this type of request be submitted through Feedback Assistant, Developer Forums, or another channel? I have corpus-based frequency data and long-press mapping data for many Cyrillic-based languages and would be happy to share it if useful. Thank you. Ali Kuzhuget

My app is written with Spanish declared as the original, base language. I have localized to 5 other languages. English, German, Italian, French, and Portuguese. If I have someone who's phone is set to an unsupported language, like Polish, and they don't have one of my supported languages in their list of "Preferred Languages" (Settings -> General -> Language and Region), then the app defaults to Spanish. Is it possible to force my app to default to English instead, without changing the original, base language declaration of the app? It appears that making that change is pretty difficult, according to documentation.

In this iOS app, with UIKit in Swift, I create a UISegmentedControl in stroryboard. I define the text for each segmentTitles in IB ,and need to localise. I have tried in the main.xxx files "id.segmentTitles" = ["a", "b", "c", "d", "e"]; to no avail. I understand this is a very very old issue that UISegmentedControl are not localized from stroryboard: https://stackoverflow.com/questions/12884751/uisegmentedcontrol-and-localization I tried to use a similar approach as for UITextView (which are not either localized) helpTextView.text = NSLocalizedString("id.text", tableName: "Main", comment: "helpTextView") But cannot make it. I found a work around, by localising in code: let seg0 = NSLocalizedString("a", comment: "Segment") segmentedControl.setTitle(seg0, forSegmentAt: 0) However, I get error messages in log unless I clear the segment titles in IB: ERROR: id.segmentTitles[0] not found in table Main of bundle CFBundle 0x600003b101c0 Is there a solution to this ?

I have this code struct TestAppleSuggestion: View { @Environment(\.locale) var locale: Locale var body: some View { VStack { VStack { Text("locale: \(locale.identifier)") Text(AttributedString(localized: LocalizedStringResource( "welcome", locale: locale ))) Text(AttributedString(localized: "welcome", locale: locale )) } } } } #Preview { TestAppleSuggestion().environment(\.locale, Locale(identifier: "fr-CA")) } Heres What I see in SwiftUi Previews The Localization is working for the LocalizedStringResource but not to the AttributedString. Why?