Hi. I have chosen a name for my new app, which isn't available in "English U.S.". When uploading it to TestFlight using Xcode, I get. The app name you entered is already being used. If you have trademark rights to this name and would like it released for your use, submit a claim. I changed the primary (and only) language from "English U.S." to "English U.K." and the app name is now accepted by App Store Connect. The app is supposed to be worldwide available and doesn't target any specific geographical region. It's also only available in English (no localizations). Are there any disadvantages using "English U.K." i.s.o. "English U.S."? What are the differences between both when it comes to App Store presentation, ranking, search, ... I don't really see why Apple offers 4 English languages. Every style understands the other one, despite some minor spelling differences.

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.

We’re looking to localize our App Store listing with different metadata (app name, description, etc.) for India and the UAE, both in English. In Xcode, we’ve already added .lproj folders for en-IN (English - India) and en-AE (English - UAE), and confirmed that the localized content is present in the bundle. However, when uploading to App Store Connect, we do not see English (India) or English (UAE) as available storefront metadata options. This is a problem because our current English (UK) metadata is UAE-specific (includes VAT, TRN, etc.), but users in India are seeing that same listing, even though it doesn’t apply to them (India uses GST, e-way bill, etc.). Our questions: 1. Are region-specific English variants like en-IN or en-AE supported for App Store metadata localization? 2. If not, is there an alternative way to offer different storefront experiences (e.g., name, description) for India and UAE? 3. Can this be achieved via custom store territories or another mechanism? Our goal is to tailor the App Store listing specifically for users in India and UAE, both in English.

Just repro'd in the latest Xcode 26 Beta 3. Building an iOS app using xcstrings for localization. We have a URL that uses percent encoding for a query param. For example: Upon compiling in the latest Xcode 26 beta this fails with: Unable to create a Swift type from the format specifier “%20S”. This was not the case in prior Xcode versions.

Why is "generate comment" button grayed out? I'm running macOS Tahoe Beta 2, Xcode 26 Beta 2 Apple intelligence on both system preferences as well as Xcode are enabled Created fresh Xcode project to test it (happens on my older project too) Xcode Preferences -> Editing -> Automatically generate string catalog comments (tried with ON/OFF) Tried to CMD+B to re-index project Not sure what else to try.

In WWDC25 Video "Explore localization with Xcode" they show how to use generated symbols from string catalogs. This is a great feature and I'd like to use it. However most of my code is split across smaller SPM packages. In the video they say at 19:20: Finally, generated symbols help you avoid boilerplate code in frameworks and packages. I've been able to use the refactoring tool to convert strings from my catalog to use generated symbols. Afterwards the code doesn't compile anymore: Type 'LocalizedStringResource' has no member '' Unfortunately the video only showcases this for frameworks but not for packages. Since they clearly speak about packages I'd like to learn how to use the feature for my packages.

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?

If I do this: NSString *name = @"Jim"; NSMenuItem *menuItem = [[NSMenuItem alloc]init]; // Analyze does show localization warning when format string is used. menuItem.title = [NSString stringWithFormat:@"Hello %@",name]; I expect to get the following warning: User-facing text should use localized string macro But I don't. However if I do this: menuItem.title = @"What"; I do get the warning about localization as expected and as desired when I run Analyze. Is this considered a bug? Thanks!

Xcode automatically generates an InfoPlist.xcstrings file for all targets, even framework targets. In frameworks, this doesn't include any user-facing content - it only has the bundle name and the copyright string. But neither of these are going to be used by users. Is there a way to tell Xcode that it doesn't need to generate these xcstrings files for content that is not user-facing?

I need to display a different app name based on the user's region/language. This setup works correctly for regions like the United Kingdom, Australia. However, for Singapore, the app always falls back to the UK version (en-GB) instead of picking the localized name defined under en-SG. Interestingly, system alerts like location permission and app deletion do use the en-SG localization correctly. Could you help identify why the app name isn't picking up the en-SG version and suggest how we can resolve this?

I initially released my app in English only and after about a year I added support for 4 more languages, now English is not being shown in the list of languages on the App Store. The primary language in App Store Connect is English (U.K.). The app seems to work fine, the content is being shown in English for me. Anyone know how I could fix this?

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

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! The localization isn't working when using SubscriptionStoreView. The app hasn't been published yet. The subscription has been created and localization strings have been added. Status - ready to submit. Testing environment: Sandbox When calling SubscriptionStoreView, the debug console shows this error: GenerativeModelsAvailability.Parameters: Initialized with invalid language code: ru-RU. Expected to receive two-letter ISO 639 code. e.g. 'zh' or 'en'. Falling back to: ru Despite this, the subscription interface appears in English when Russian is expected. I don't use any locale setting for ru-RU anywhere in my code. The test device's region is set to Russia, and the language is Russian. Any help would be appreciated.

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.

I'm trying to programmatically create an Advanced AppClip Experience via the API. following the docs https://developer.apple.com/documentation/appstoreconnectapi/app-clips-and-app-clip-experiences I have created the header image. But when I try to create the experience I can not figure out a) how to create a localisationID to be included in the relationships object b) how to get the included object to be recognised Any one have experience or can offer help?

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

Hello, I would like to report a critical issue with Arabic text rendering in SwiftUI apps on iOS and iPadOS. When using Arabic as the default language (Right-to-Left - RTL), Arabic text appears reversed and disconnected inside several SwiftUI components like: List Section TextField Picker Custom views (like StudentRowView) Even though the environment is set to .layoutDirection(.rightToLeft), the dynamic Arabic text is not rendered properly. Static headers display correctly, but any dynamic content (student names, notes, field titles) becomes broken and unreadable. Examples where the issue occurs: AboutView.swift → Arabic text inside List and Section SettingsView.swift → TextField placeholders and Picker options StudentRowView.swift → Student names and grade field titles Environment: SwiftUI 5 (Xcode 15+) iOS 17+ Reproducible 100% on both Simulator and real devices. Expected Behavior: Arabic text should appear properly connected, right-aligned, and readable without any manual workaround for each Text or TextField. Workarounds Tried: Manually setting .multilineTextAlignment(.trailing) (inefficient) Wrapping every Text inside an HStack with Spacer (hacky) Building custom UIKit views (defeats purpose of SwiftUI simplicity) Formal Feedback: I have submitted a Feedback Assistant report We hope this issue will be prioritized and fixed to improve SwiftUI's support for Arabic and other RTL languages. Thank you.

In order to make referencing keys for localized strings a little more reliable, our application references generated constants for localized string keys: This eliminates the potential for developers to misspell a key when referencing a localized strings. And because these constants are automatically generated by the exact same process that provides localized strings for the application, each and every constant is guaranteed to have a localized string associated with it. I’m currently attempting to implement something similar for the localized strings referenced by our new App Intents. Our initial release of App Intent functionality is simply using string literals to reference localized strings: However, I am running into several issues when trying to reference the string keys as a constant. The closest I managed to get was defining the constant as either a LocalizationValue or as a StaticString and referencing the constant while initializing the LocalizedStringResource. With this approach, I see no errors from Xcode until I try and compile. What’s more is that the wording of the error being thrown is quite peculiar: As you can see with the sample code above, I am clearly calling LocalizedStringResource’s initializer directly as Indicated by the error. Is what I’m trying to do even possible with App Intents? From my research, it does look like iOS app localization is moving more towards using string literals for localized strings. Like with String Catalog’s ability to automatically generate entries from strings referenced in UI without the need for a key. However, we’d prefer to use constants if possible for the reasons listed above.

Hi everyone! I’m a new developer diving into my first Apple Watch project, and I’m really excited to get started! This app relies heavily on using the most precise location data possible. Could anyone point me to some official documentation or helpful resources on how to achieve high-accuracy location tracking specifically for watchOS? Any tips or best practices would also be greatly appreciated! Thanks in advance for your help!