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.

Hi there dear Apple team. Would really appreciate if you can see my post. It‘s 2026 and Apple still doesn’t support Azerbaijani keyboard predictive text. please please can you work on it and add this feature in Apples keyboard. thanks

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 ?

We are testing Apple Universal Links for ios.aierchina.com. The domain is ICP-registered and hosted in mainland China. The problem: Apple's CDN always returns “not found” for our AASA file: https://app-site-association.cdn-apple.com/a/v1/ios.aierchina.com What we have verified: The AASA file is correctly served at both /.well-known/apple-app-site-association and /apple-app-site-association Returns HTTP 200, valid JSON, correct Content-Type, no redirects, valid SSL Server response time is under 500ms What works: Adding ?mode=developer to the applinks entry works perfectly Universal Link Diagnostics on device (ios.aierchina.com/uat) correctly resolves to our app bundle What does not work: Production mode fails because the Apple CDN never caches our AASA file Reinstalling the app does not help Server logs show occasional requests from com.apple.swcd, but CDN still returns 404 Questions: Are there known issues with Apple CDN caching AASA files for China-hosted domains? Is there any way to force Apple's CDN to re-crawl our domain? Could the GFW or regional network policies be interfering? What was the fix?

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

Hi, my apps are build the way, that it always should take the localization based on the system language. I had/have the issue, that sometimes it falls back to english. I assume, that the configured user language isn't fully localized. you can see that especially when using date and time formats and calendars. how do I prevent that? or: how is the correct way to implement localization in an app? thanks in advance

Are these two things the same? If not, how are they different?

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.

I'm really excited about the new localization features in the 27 OSes. What languages does Xcode 27 support via agentic localization?