NavigationTitle does not change when the app language changes. It works well in iOS 17.5 but does not in iOS 18.x

I published several apps in the past that display the correct languages in the App Store, but my newest app, which has English as the default development language in Xcode, displays all languages set in Xcode except English. My other projects seem to be set up in the exact same way, except they display correctly. What could be the issue? Xcode project info: Localizable.xcstrings (English is also fully localized): App Store Connect website: App Store page (my Mac has the primary language set to Italian):

I have two call directory extensions, each with InfoPlist.strings in en.lproj and nb.lproj directories. In these files I've defined CFBundleDisplayName for both locales. These names are displayed under Settings -> Phone -> Call Blocking & Identification. On iOS 12.2 the names are displayed correctly in both Norwegian and English. Testing on iOS 15.3 the English names are displayed even when device language is set to Norwegian. Worth noting: When updating the English versions of CFBundleDisplayName this is immediately reflected in Call Blocking & Identification page with Norwegian device language. As this feature requires a real device, I'm unable to test on iOS 13 and 14.

Is it possible to build localization into console apps, developed in SwiftUI in Xcode26. I have created a catalog, (.xcstrings file) with an English and fr-CA string. I have tried to display the French text without success. I am using the console app to test a package which also has English/French text. English text works fine in both package and the console main, but I cannot generate the French. From what I can discover so far it's not possible without bundling it as a .app, (console app). Looking for anyone who has crossed this bridge.

We’ve noticed an issue where after running a network extension, if the phone’s language is changed the Locale.preferredLanguages array is not updated and still returns the old array. It only returns the updated array when the app is reinstalled or the phone is restarted. This is unlike the app itself where using the same Locale.preferredLanguages API immediately returns the updated array. We think this issue is also the cause of notifications that are sent by the network extension being in the previous language as long as the app isn’t reinstalled or the phone is restarted, despite our Localizable file having localised strings for the new language. Feedback ID: FB20086051 The feedback report includes a sample project with steps on how to reproduce the issue.

I'm working on a large multi-platform iOS project (iOS, iPadOS, watchOS, tvOS, visionOS) and have successfully migrated from legacy .strings files to modern String Catalogs (.xcstrings). However, I'm unable to export localizations using xcodebuild -exportLocalizations due to cross-platform framework dependency issues. (Note: I did have AI help me write this question, so apologies in advance for any errors) Project Structure Main iOS/iPad app with multiple extensions watchOS companion app tvOS app visionOS app 49 .xcstrings files successfully migrated across all targets Uses Swift Package Manager for modularization The Problem When attempting to export localizations using xcodebuild -exportLocalizations, the build fails because it tries to build all targets across all platforms, including watchOS targets that depend on third-party xcframeworks that don't include watchOS slices: xcodebuild -exportLocalizations \ -project MyProject.xcodeproj \ -scheme MyApp \ -localizationPath ./export \ -configuration Debug Error: error: While building for watchOS, no library for this platform was found in 'Frameworks/<incompatible>.xcframework'. (in target 'Target') These frameworks cannot be modified to add watchOS support (third-party/legacy dependencies). What Works vs. What Doesn't Works: Building the iOS app through Xcode GUI Fails: Exporting localizations through Xcode GUI (Product → Export Localizations...) Fails: xcodebuild -exportLocalizations with any combination of flags Attempted Solutions (All Failed) Platform-specific destination: xcodebuild -exportLocalizations -destination "generic/platform=iOS" ... SDK constraint: xcodebuild -exportLocalizations -sdk iphoneos ... Excluding architectures: xcodebuild -exportLocalizations EXCLUDED_ARCHS="armv7k arm64_32" ... Build first, then export: xcodebuild build -scheme MyApp -sdk iphoneos && \ xcodebuild -exportLocalizations ... All approaches still attempt to build watchOS targets despite platform constraints. Observations The -exportLocalizations flag appears to ignore -destination and -sdk flags It seems to scan and build ALL schemes/targets in the project regardless of constraints Regular builds (xcodebuild build) work fine with platform constraints Current Workaround I created a Python script that parses .xcstrings JSON files directly and generates XLIFF output, which works but feels like it's bypassing Apple's intended workflow. Questions for Apple Is there a way to limit xcodebuild -exportLocalizations to specific platforms? The documentation doesn't mention any flags for this, and -destination/-sdk appear to be ignored. Why does -exportLocalizations require building ALL targets across ALL platforms? Both the Xcode GUI (Product → Export Localizations) and xcodebuild -exportLocalizations fail with identical build errors, suggesting this is by design. Is there a reason localization export can't be limited to buildable targets? Is the intended workflow to have ALL targets buildable across ALL platforms before exporting localizations? This seems impractical for multi-platform projects with platform-specific dependencies. Are there any build settings or configuration options that can exclude specific targets/platforms from the localization export scan? Is directly parsing .xcstrings files and generating XLIFF an acceptable alternative, or does this miss important metadata that -exportLocalizations would include? Environment Xcode 16.x / 26.x (reproduces on both) macOS Tahoe Project uses String Catalogs (.xcstrings) format Mixed SPM packages and traditional target structure Any guidance on the correct approach for multi-platform localization export would be greatly appreciated. Is this a known limitation, or is there a recommended pattern I'm missing?

We have separated much of our UI into different packages to reduce complexity and compile time. When we recently tested using new .xcstrings string catalogs, we hit an unexpected problem. Strings extracted from SwiftUI components like Text or Button are extracted into the Localizable.xcstrings in the same package, but the default behaviour of Text(_ key:tableName:bundle:comment:) is to use Bundle.main. When the default behaviour of the string extraction isn't to extract to the main app target, this introduces a very fragile system where it's easy to add code that looks localised, but ends up failing lookup at runtime. I don't feel comfortable that we will always remember to define the correct module every time we create a Text. Also, other components like Button doesn't have an init that takes a Bundle, so we would also have to remember that Button(_ titleKey:action:) can now only be used in a package if we make sure that the main bundle contains a matching key. Is there a way for us to make sure that strings are always extracted to the same place as they are resolved against by default? Either by having strings in packages extracted to an xcstrings file in the main app or having Text default to resolving against the module bundle by default?

It seems that Xcode gets confused when there is another format specifier before a plural variable. As shown in the screenshot, %#@VARIABLE@ %f works fine, but an error occurs with %f %#@VARIABLE@.

We are building a Multi-Lingual Business Application -- where the user is able to enter values and data in multiple languages. One of our main use cases is, if a user is editing or adding to a text value or data that is in a different language. For example, the data they are editing could be in Japanese, and the user's current input language is set to English, then when they enter the editing mode, the input language is automatically set to Japanese by us -- programmatically. They can go back to editing English items, and the input language is changed back to English, and similarly, when they come back to edit the Japanese data or some German data, then the input language is again automatically changed to the respective language by the application -- without causing the user to manually go to the settings and change it. Is there any current way to have this behaviour in MacOS and iOS now? Please suggest what can be done to achieve the same.

I am trying to localize the CFBundleDisplayName and OSBundleUsageDescription of a driver that is part of an app. I am able to use InfoPlist.strings files to localize the Bundle display name for the app, but when I try to use the same file as part of the driver, the name displayed in settings for the app does not change correctly. In fact, it seems to follow the default language set in the xcode project. If the default language is not included in the suite of InfoPlist.strings files, it seems to take the string from the info.plist file. sometimes it just seems to take the English version regardless of the default language or tablet language. Has anyone had success with this?

I'm writing an iOS app that shares content with buddies. So my app will run in one language but the shared content will use the locale configured for the buddy. I found this Apple documentation which suggests that locale: (Locale(identifier: is the solution. Apple Documentation But I can't get it to work. Here's sample code. struct LocalizationDemoView: View { @State var isEnglish = true var body: some View { var myLocale: String { isEnglish ? "en": "de" } VStack { Toggle("Switch language", isOn: $isEnglish).frame(maxWidth: 200) HStack { Text("\(myLocale): ") Text(String(localized: "Hello world!", locale: (Locale(identifier: myLocale)), comment: "To share")) } } } } And here's the excerpt from the string catalog: { "sourceLanguage" : "en", "strings" : { "Hello world!" : { "comment" : "To share", "localizations" : { "de" : { "stringUnit" : { "state" : "translated", "value" : "🇩🇪 Moin Welt!" } }, "en" : { "stringUnit" : { "state" : "translated", "value" : "🇬🇧 Hello world!" } } } } } } Has Apple reduced support for string catalogs or is my code wrong? Xcode 16.4 compiled on MacOS 15.6.1, device iOS 18.6.2

Hi everyone, I’ve run into a strange localization issue with macOS document-based apps in SwiftUI/AppKit. I created a standard document-based macOS app in Xcode (SwiftUI template) and added a French localization to the project. All system-generated menu bar commands (File → New, Close, Print, etc.) are correctly translated into French… except for “Save”, which remains in English. To rule out problems in my own code, I created a fresh, unmodified document-based app project in Xcode, and immediately added French localization without touching any code. Same result: all commands are translated except “Save”. This suggests the issue isn’t specific to my app code, but either the project template, or possibly macOS itself. My environment • Xcode version: 16.4 • macOS version: 15.6.1 Sequoia] • Swift: Swift 6 Questions 1. Has anyone else seen this issue with the “Save” command not being localized? 2. Is this expected behavior (maybe “Save” is handled differently from other menu items)? 3. If it’s a bug in the template or OS, is there a known workaround? Thanks for any insights P.S. Please note that I'm a total beginner

I reported Korean IME bug to QT Bug report. Please refer to below link. https://bugreports.qt.io/browse/QTBUG-136128?jql=text%20~%20korean%20ORDER%20BY%20created%20DESC But, QT reponsed me like follwing. Thank you for reporting. However, this issue seems like a known issue with apple's Korean IME. There are many threads in Korean community about the same problem with Non-Qt apps. If this issue is a really Qt issue, feel free to open it again. Is there any workaround to fix this IME bug ? Thanks, Ted

In iOS 26, AVSpeechSynthesizer read Mandarin into Cantonese pronunciation. No matter how you set the language, and change the settings of my phone system, it doesn't work. let utterance = AVSpeechUtterance(string: "你好啊") //let voice = AVSpeechSynthesisVoice(language: "zh-CN") // not work let voice = AVSpeechSynthesisVoice(language: "zh-Hans") // not work too utterance.voice = voice et synth = AVSpeechSynthesizer() synth.speak(utterance)

When using Foundation Models, is it possible to ask the model to produce output in a specific language, apart from giving an instruction like "Provide answers in ." ? (I tried that and it kind of worked, but it seems fragile.) I haven't noticed an API to do so and have a use-case where the output should be in a user-selectable language that is not the current system language.

Hi, My iOS app's home screen widget content was implemented to base on the preferred language of my main app (e.g. my app has the following preferred language options with this order English, Japanese, Traditional Chinese, Korean, Simplify Chinese). Say the main app is currently using English as their preferred language, I can change the preferred language in the iOS Settings -> Apps -> My App -> Preferred Language. My widget's content will respect to the preferred language option that I selected with only exception if I switch back to English language and my Widget's content won't get updated. The Main app content is always update with respect to the selected preferred language. My app and widget is working without any issue in iOS 18. Other things that I had discovered during my testing under iOS 26, the "first" language appeared in my preferred language always being the issue (e.g. if the first language is Japanese , once I change to other languages and than switch back to Japanese, my widget content won't respect to this but the main app content are ok). Any one has a similar issues regarding the preferred language?

Hi! I have defined the following app intent. It returns a result with a dialog to confirm that the intent has been executed. Naturally, that dialog needs to be localized properly. But the String interpolation with the provided format doesn't do that. I specified wide for the width parameter and expect spelled-out unit names. However, in the textual output, Siri always uses the abbreviated unit (e.g. "min" or "s"), in all languages I tested. In the audio output, Siri says "minutes" in English where the textual representation is "min". In German, Siri says "min", so it basically reads the textual representation aloud and that's not quite understandable to the user. struct StartTimerIntent: AppIntent { static let title: LocalizedStringResource = "Start New Timer" static var description = IntentDescription("Starts a timer with a custom duration.") @Parameter(title: "Duration", description: "The duration of the timer.") var duration: Measurement<UnitDuration> func perform() async throws -> some IntentResult & ProvidesDialog { // [code to execute intent goes here] return .result( dialog: .init( full: "\(duration, format: .measurement(width: .wide, usage: .asProvided)) timer started.", systemImageName: "timer" ) ) } } As this SwiftUI-style formatter doesn't seem to work with localization, I tried a different approach with a MeasurementFormatter: extension Measurement where UnitType == UnitDuration { func localized() -> String { let formatter = MeasurementFormatter() formatter.locale = .autoupdatingCurrent formatter.unitOptions = .providedUnit formatter.unitStyle = .long return formatter.string(from: self) } } Usage with String interpolation: "\(duration.localized()) timer started." This works great as long as these two languages are set to the same language on the user's device: [UI language] Settings → General → Language & Region → Preferred Language [Siri langauge] Settings → Apple Intelligence & Siri → Language However, when they differ, even this method doesn't yield correct results. For example, I have my general (UI) language set to English, but my Siri language set to German. Then Siri replies in German, but the unit is formatted in English and Siri speaks it in English, so the result is a messed up sentence that's half German, half English. What is the proper way to localize parameters in dialogs for Siri? How can I make sure that parameters are localized to match Siri's language?

If you add a new string in your app (for example String(localized: "contact_support_message", defaultValue: "Please contact support")), then later you change that default value and rebuild, the string catalog updates to match as expected. But once that string is translated, changing the default value in code and rebuilding does not update the catalog. You seemingly have to go manually change the default value for English in the catalog to match the code (which marks the translation as Needs Review). Is there a better way? Or is there a way to determine what strings have default values in code that do not match the catalog values to see if any were missed as wording was tweaked over time?

Hi all, I have repeatedly the issue that a certain .strings file in my app's bundle has the extended files attribute com.apple.quarantine set. Consequently the submission fails with the following mail notification: We noticed one or more issues with a recent delivery for the following app: [...] ITMS-91109: Invalid package contents - The package contains one or more files with the com.apple.quarantine extended file attribute, such as “abcdef.strings”. This attribute isn’t permitted in macOS apps distributed on TestFlight or the App Store. Please remove the attribute from all files within your app and upload again. I'm able to resubmit the bundle after cleaning the file attribute via xattr -d -r com.apple.quarantine..., but the funny thing is it happens again and again - on a .strings file which hasn't been downloaded (but manually created), shouldn't be under Gatekeeper's quarantine, and wasn't edited in the meantime. Is anybody else observing the same issue with macOS 15.4.1, Xcode 16.3? Greetings, Matthias

Hello, I am trying to localize my app in other languages. Most of the text are automatically extracted by Xcode when creating a string catalog and running my app. However I realized few texts aren't extracted, hence I find a solution for most of them by adding For example I have some declared variable as var title: String = "Continue" Hence for them to be trigger I changed the String by LocalizedStringResource which gives var title: LocalizedStringResource = "Continue" But I still have an issue with some variables declared as an array with this for example @State private var genderOptions = ["Male", "Female", "Not Disclosed"] I tried many things however I don't success to make these arrays to be translated as the word here "Male", "Female" and "Not Disclosed". I have more array like that in my code and I am trying to find a solution for them to be extracted and be able to be localized Few things I tried that doesn't worked @State private var genderOptions : LocalizedStringResource = ["Male", "Female", "Not Disclosed"] @State private var genderOptions = [LocalizedStringResource("Male"), LocalizedStringResource("Female"), LocalizedStringResource("Not Disclosed")] Any idea more than welcome Thank guys