Before migrating to xcstrings for i18n, our project used Xcode's base localization. We want to preserve that pattern after the migration, but haven't found a clean way to do it. First attempt — a "base" identifier in both the project configuration and the xcstrings files. This fails: the compiler inconsistently emits either a base.lproj or a Base.lproj folder, and the casing mismatch breaks the App Store Connect upload. Fallback — a "und" entry, "Undetermined" under ISO 639-2, which Apple documents as a valid language identifier. This behaves correctly at every visible step: the build generates a und.lproj folder, as expected; the ASC upload succeeds with no warning; "Undetermined" appears in the ASC list of available languages; the build is downloadable on TestFlight and distributable on the App Store, with no warning. But there's one silent failure: once a "und" build is shipped, the app/version becomes invisible — on the App Store, on iOS, and on the website. We currently work around this by stripping every "und" entry from the project before shipping. But we genuinely need the base-localization pattern, and this manual removal isn't something we're comfortable relying on. Is there a supported way to keep a neutral/base localization in xcstrings that both passes ASC upload and stays visible on the store?

Hi there, I’m curious to understand how the system determines which language to use for an app. The system is currently set to en-IN (English - India). My app supports the following languages: en (the default development language) en-GB (United Kingdom) en-IE (Ireland) en-US (United States) When I run the app, the Bundle.main.preferredLanguages returns [„en-GB“, „en“], which causes the app to be set to en-GB. However, when the app doesn’t support the preferred system language, I would expect it to default to the en language. Surprisingly, this is not the case. This behavior is precisely described in Technical Note TN2418. Unfortunately, there’s no explanation provided. Is this behavior related to the CLDR Linguistic Distance? I also attempted to replace the default development language en with en-001 (English - world), but it had no effect.

We format times in a localized way using the DateFormatter APIs.DateFormatter.localizedString(from: date, dateStyle: .none, timeStyle: .short)However if the result of this localization is say "22:00" VoiceOver just reads this out as "22". The VoiceOver user is given no indication that this numeric value is a time of the day.I've read online that one approach is to use DateComponentsFormatter and the spellOut unitsStyle e.g.let hourComponents = Calendar.current.dateComponents([.hour, .minute], from: date) cell.accessibilityLabel = DateComponentsFormatter.localizedString(from: hourComponents, unitsStyle: .spellOut)But again for a time "22:00" this reads out "22 hours". Sure if gives more context that this is related to time but it doesn't really indicate it is a time of the day i.e. it could be an interval (22 hours until something happens).We've trawled through the Apple documenation but we can't find anything that covers this.The best possible workaround we've found would be to force the accessibility label to be read out in 12 hour time i.e.let dateFormatter = DateFormatter() dateFormatter.setLocalizedDateFormatFromTemplate("hh:mm") accessibilityLabel =dateFormatter.string(from: date)that way it is clear to the user that it is a time of the day. Although this approach has the downside that ignores the user's preference of a 24 hour or 12 hour time display.The VoiceOver readout is handled perfectly in the Calendar app. It reads out "10 o'clock" and "22 hundred hours" in English and it is fully localized so for example it reads out "midi" for 12:00pm in French. It is possible that this is being done with private APIs though.So my question is, what is the recommended approach for formatting times for VoiceOver?

To the Apple iOS Development and Accessibility Teams, I am writing to formally request the addition of a native Lisu keyboard to iOS. As Apple continues to expand its global accessibility and language support, adding the Lisu language would bridge a significant communication gap for a vibrant and growing community. About the Lisu People: The Lisu are a Tibeto-Burman ethnic group with an estimated population of over 1.4 million. They traditionally inhabit the mountainous regions of Myanmar (Burma), Southwest China (particularly the Yunnan and Sichuan provinces), Thailand, and the Indian state of Arunachal Pradesh. They possess a rich cultural heritage, passed down through generations via extensive oral traditions, songs, and clan histories. The Lisu Language and Fraser Script: The Lisu language is officially supported by the Unicode Consortium. The writing system, known as the Fraser script, was developed in 1914 and was officially added to the Unicode Standard in Version 5.2. Unicode Reference: The Lisu block is designated at U+A4D0 – U+A4FF. Official Chart: Unicode [Lisu Chart (PDF)] https://www.unicode.org/charts/PDF/UA4D0.pdf Current Industry StandardsOther major operating systems have already recognized the importance of supporting the Lisu community: Microsoft Windows: Currently comes with a pre-installed Lisu keyboard, allowing users to type seamlessly out of the box. Android (Google): The default Gboard natively supports the Lisu keyboard, offering full mobile typing capabilities for Android users. Currently, iOS users who speak and write in Lisu must rely on third-party workarounds, which often lack the security, privacy, and seamless integration of Apple’s native keyboards. By implementing the Lisu keyboard, Apple would greatly enhance the iOS experience for over a million people, allowing them to communicate natively on their iPhones and iPads.Thank you for your time, consideration, and ongoing commitment to making technology accessible to everyone. I look forward to seeing Lisu supported in a future iOS update. Sincerely, Si_Gwa

Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog

Hi, Overview: I have a project in which: Some files are only in the app target Some files are only in the widget target Some files are in the app and widget target (both targets) Now I would like to add string catalog for localization where strings would automatically detected from the project. Questions: Should I add a separate strings catalog for app target and widget target? What about the code shared between the 2 targets, do I have to do the translations twice for strings corresponding to files belonging to both app and widget target? What is the best approach for my project?

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.

Hi everyone, I’m trying to switch my app’s Primary Language from Simplified Chinese to English (US) in App Store Connect. When I hit save, I receive this error message: You have one or more errors on this page. Primary Language couldn’t be saved because another field is invalid. The problem is no specific invalid field is pointed out by the UI. There is no highlight, no hint telling me exactly what is wrong. I’ve already contacted Apple Developer Support. They checked my backend account and said there are no obvious issues on their side, and suggested I post here for community assistance. I have filled out all required metadata fields for English (US), including app name, subtitle, description, keywords, support URL, privacy‑policy URL, and uploaded all required screenshots. All assets are ready. I have attached screenshots showing my configuration and the error popup. It is really confusing that App Store Connect throws a generic error without pointing to which exact field is causing the validation failure. Has anyone run into this exact error? What hidden requirements or possible gotchas should I check? Any advice would be greatly appreciated. Thank you.

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?

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.

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.

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