Hi, I’ve been wondering how Apple calculates Gigabytes in Finder, as I haven’t been able to find any function that yields the result shown. I would like to convert 1,303,412,493 Bytes. It says 1.3 GB in the top right corner, which matches my own conversion. let byteCountFormatStyle = ByteCountFormatStyle(style: .file, allowedUnits: .all, spellsOutZero: false, includesActualByteCount: false, locale: Locale.current) let sizeFormatStyle = byteCountFormatStyle.format(Int64(1_303_412_493)) let byteMeasurement = Measurement(value: Double(1_303_412_493), unit: UnitInformationStorage.bytes) let sizeMeasurement = byteMeasurement.formatted(.byteCount(style: .file)) print("sizeFormatStyle: \(sizeFormatStyle), sizeMeasurement: \(sizeMeasurement)")Both are the same: sizeFormatStyle: 1.3 GB, sizeMeasurement: 1.3 GB But how do I arrive at the 1.51 GB figure that appears next to the Byte count? Christian

Hello there, I submit my documentation for France about: App Encryption Documentation on Sep 24, 2026 and it still "In Review". Anyone had this kind of delay? Thank you.

Hello, I’m trying to determine whether Albanian (sq) and Macedonian (mk) are supported as full system display languages on iOS. When I go to: Settings → General → Language & Region → iPhone Language Albanian and Macedonian are not available as system languages. However, both languages appear to have support in other parts of iOS. For example, Apple currently lists Albanian and Macedonian among the supported QuickType keyboard languages. 
https://www.apple.com/in/ios/feature-availability/?utm_source=chatgpt.com I have tested this behavior on: - iOS 16.7 - iOS 17.5 - iOS 26.6.1 - iOS 27.0.1 In all tested versions, I cannot change the iPhone system/display language to Albanian or Macedonian. I would like to clarify: 1. Are Albanian (sq) and Macedonian (mk) officially supported as iOS system/display languages? 2. If they are not supported, is there an official Apple documentation page listing the supported iOS system languages? 3. Is there any API or mechanism available to an app to determine whether a language is supported as a system UI language, as opposed to being supported only for keyboards or other language features? 4. Are there plans to add Albanian and Macedonian as full iOS system languages? I understand that app localization is separate from the iOS system language. Apple documentation explains that an app's localization is determined from the user's preferred languages and the localizations provided by the app. 
https://developer.apple.com/library/archive/qa/qa1828/_index.html?utm_source=chatgpt.com https://developer.apple.com/documentation/foundation/locale/preferredlanguages?changes=_11&utm_source=chatgpt.com I’m specifically asking about Apple's own iOS system UI, not localization of a third-party application. Expected: Selecting Albanian or Macedonian as the iPhone language should make the iOS system UI appear in that language, if the language is supported. Actual: Albanian and Macedonian cannot be selected as the iPhone's system/display language. Could someone from Apple confirm whether this is expected behavior and whether these languages are currently unsupported as full iOS system languages? Thank you.

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.

I’m seeing inconsistent right-to-left behavior when using the new SwiftUI swipeActionsContainer() API with a ScrollView. The swipe-action buttons are positioned correctly according to the layout direction, but the gesture direction itself is not mirrored. Minimal reproducible example: import SwiftUI struct ContentView: View { var body: some View { ScrollView { LazyVStack { Text("Hello, World!") .padding() .frame(maxWidth: .infinity) .background(.blue.quinary) .swipeActions { Button(role: .destructive) { // Delete action } label: { Label("Delete", systemImage: "trash") } } } .padding() } .swipeActionsContainer() } } Steps to reproduce: Run the example using a left-to-right language such as English. Swipe the row from right to left. The trailing swipe actions appear correctly. Change the app language to Arabic. Swipe the row from left to right, which should reveal the trailing actions in an RTL layout. Nothing happens. Swipe from right to left instead. The actions appear, but from the correct visually mirrored edge. Expected behavior: Because the default swipe-action edge is .trailing, both the action placement and the gesture direction should follow the current layout direction: English/LTR: swipe from right to left. Arabic/RTL: swipe from left to right. Actual behavior: The action buttons visually respect the RTL layout, but the gesture recognizer still requires the LTR swipe direction. Environment: Xcode: 27.0 RC iOS: 27.0 RC Device: iPhone 17 Swift language version: Swift 6

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.

I have a WebView App for my WordPress site. For multilanguage support I am using gTranslate. This works fine on any browser (also Safari) and also in my App on Android - but it does NOT work on iPhones. gTranslate is using GoogleTranslate. On iPhones it is kicked on correctly, but just does not translate the page. Do you have any clue why this is the case? What is hindering gTranslate (Google-Translate) to run on iPhones? My WebViews is starting with this - do I need something special for iOs?: <WebView style={{ flex: 1 }} ref={webViewRef} source={{ uri: initialUrl }} applicationNameForUserAgent={APP_AGENT} javaScriptEnabled={true} domStorageEnabled={true} sharedCookiesEnabled={true} cacheEnabled={false} thirdPartyCookiesEnabled={true} originWhitelist={['*']} setSupportMultipleWindows={false} startInLoadingState={true} .... If you don't know a solution: Is there another service I can or should use for iPhones? What I want to achieve is: The app should start (automatically) in the language of the user (from device-locales) - on iPhone in the same way like on Android. BTW: I don't habe an iPhone and therefore can't test myself. I receive the messages from my users.

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.

when we launch the application and change the language from german/french to english or any other language then in also it is changing app language, but bluetooth connection screen with pair or cancel alert is showing on previous selected language. Since that alert is system alert, is there any wayto debug/resolve that issue.

I logged in to macOS with my localization language. try to perform following code. but always get "Documents". What do I miss? Apple Swift version 5.2.4 macOS 10.15.6 Xcode 11.6 code let paths = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true) if paths.count &gt; 0 {     let doc = FileManager().displayName(atPath: paths[0])     print(doc) } result Documents

Hello, help needed! I released an app to all 175 countries on March 5, 2026. However one of my testers notified me, that the app isn't shows up while being searched in New Zealand. I validated the issue. The US App Store link works: https://apps.apple.com/us/app/heartble-heart-rate-bluetooth/id6758879454 However, if I switch to New Zealand (in the footer on that web page) it navigates me to App Store home. Search results doesn't contain HeartBLE app: https://apps.apple.com/nz/iphone/search?term=HeartBLE Please, help! Should I create a feedback? Or maybe I missing something in the ASC setup?

When setting the language in iOS/macOS to German (or other languages with “,” decimal separator) and number format to “1.234.567,89” in iOS 26.2, 26.3 and 26.4 Beta, Safari inserts the wrong decimal separator in elements. It should use the local German decimal separator comma “,” instead it uses the english/international period “.” Here is a screenshot of iOS 26.2 when visiting a website with just 2 number inputs in Safari: <input type="number"> <input type="number" value="5.6"> It behaves the following way: On the first input, enter a number with decimals like “12,34”, clicking “,” on the onscreen-keyboard, a “.” instead of a “,” is added. The number then is formatted in international/English: “12.34”. The input set programatically shows the right decimal separator for German: "5,6". But deleting the “,” and pressing “,” on the onscreen-keyboard again adds a dot instead of a comma and shows the number in international/english: “5.6”. The same issue also happens on desktop Safari on MacOS 26.2 and newer and iOS apps using webviews, also since iOS 26.2. How to use the correct decimal separator in html number inputs for the user selected language in iOS/macOS on iOS 26.2 and newer versions? Is this maybe a bug? This was working correctly for iOS 26.1 and older:

Hi, I'm encountering a weird issue on iOS that happens: for files with diacritics in their name, like "Gòmez.pdf" or "Télé.mp4", when the iPhone or iPad main language is not set to English, if the file has been created with a relatively low-level Unix function like fopen() or copyfile(). Then, the file cannot be previsualized using QuickLook or opened using other apps. Most of the time it fails silently, but on some occasions I get the following error message: "You do not have permission to save the file "filename.pdf" in the folder "myFolder"". The issue is present in, at least, iOS 16 and 26. It seems worse in iOS 26. It seems that all three conditions are required, I don't see the issue when the iPhone or iPad is set to use English as the main language. I also don't see the issue if I rename the files in the Files app. I'm probably doing something wrong, but what can it be? (it's kind of weird that my recommendation for users becomes: if you want to use international characters in your file names, you need to set the iPad language to English...)

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)

MacOS system settings allow the user to select one of a number of number formats. My app behaves differently depending on the format (taken from the system Locale), so I need to test every combination. Thus far I have been successful at creating Locale objects with various identifiers that map to the different formats, like: let westEuropeanLocale = Locale(identifier: "en_DE") However, I can't find a locale that maps to using . as a decimal point, and space as a thousands separator, even though it's a standard option (3rd in this list): Any suggestions on how to create a test for this number format?

Introduction: I’m encountering a consistent crash in production on iOS 26.2 (build 23C55). The crash occurs deep within libicucore when calling [NSDateFormatter dateFromString:]. Crash Summary: Exception Type: SIGSEGV (SEGV_ACCERR) Fault Address: 0xffffffff Thread: Crashed on Main Thread (Thread 0) Library: libicucore.A.dylib Code Snippet: The crash is triggered by the following method. It converts a string to an NSDate using a specific format and locale: // 获取日期date - (NSDate *)getDateWithTime:(NSString *)time formatter:(NSString *)formatterStr { NSDateFormatter *formatter = [[NSDateFormatter alloc] init]; [formatter setDateFormat:formatterStr]; formatter.timeZone = [NSTimeZone timeZoneWithName:@"Asia/Shanghai"]; formatter.locale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"]; return [formatter dateFromString:time]; } Backtrace: Here is the relevant part of the crash report: Incident Identifier: E24485B6-C53E-4115-A6CF-A7E4A952AD50 CrashReporter Key: 21FAC1CF-F56B-409A-98AA-351D3D2EB06C Hardware Model: iPhone18,2 Code Type: ARM-64 Parent Process: [1] Date/Time: 2026-01-12T01:32:25Z OS Version: iPhone OS 26.2 (23C55) Report Version: 105 SDK Version: 0.0.4 Exception Type: SIGSEGV Exception Codes: SEGV_ACCERR at 0xffffffff Crashed Thread: 0 Thread 0 Crashed: 0 libicucore.A.dylib 0x000000019b81def8 0x19b74a000 + 868088 1 libicucore.A.dylib 0x000000019b7da91c 0x19b74a000 + 592156 2 libicucore.A.dylib 0x000000019b8d8340 0x19b74a000 + 1631040 3 libicucore.A.dylib 0x000000019b8eae18 0x19b74a000 + 1707544 4 libicucore.A.dylib 0x000000019b8eb600 0x19b74a000 + 1709568 5 libicucore.A.dylib 0x000000019b878be4 0x19b74a000 + 1240036 6 libicucore.A.dylib 0x000000019b87ae84 0x19b74a000 + 1248900 7 libicucore.A.dylib 0x000000019b87b2dc 0x19b74a000 + 1250012 8 libicucore.A.dylib 0x000000019b9564ac 0x19b74a000 + 2147500 9 libicucore.A.dylib 0x000000019b954afc 0x19b74a000 + 2140924 10 libicucore.A.dylib 0x000000019b952794 0x19b74a000 + 2131860 11 libicucore.A.dylib 0x000000019b98689c 0x19b74a000 + 2345116 12 CoreFoundation 0x00000001895dbfe0 0x18953d000 + 651232 13 CoreFoundation 0x00000001895dbaa0 0x18953d000 + 649888 14 Foundation 0x0000000186d2029c 0x186b88000 + 1671836 15 Foundation 0x00000001874a62dc 0x186b88000 + 9560796 16 Foundation 0x00000001874a6384 0x186b88000 + 9560964 17 xxxx 0x0000000105ea6e30 -[xxxxx getDateWithTime:formatter:] + 168 and Thread 0 crashed with ARM-64 Thread State: pc: 0x000000019b81def8 fp: 0x000000016f96bc10 sp: 0x000000016f96bbd0 x0: 0x00000000ffffffff x1: 0x000000019ba1e8e0 x2: 0x0000000000000002 x3: 0x000000000000000b x4: 0x0000000000000074 x5: 0x0000000000000069 x6: 0x0000000000000000 x7: 0xfffff0003ffff800 x8: 0x000000009ba18014 x9: 0x00000001148dffd0 x10: 0x0000000000000002 x11: 0x0000000000000004 x12: 0x0000000000000220 x13: 0x0000000000000030 x14: 0x000000015b6f36b8 x15: 0x000000015cfe0000 x16: 0x00000002a19d0ff0 x17: 0x00000001f5590a70 x18: 0x0000000000000000 x19: 0x000000016f96bc30 x20: 0x0000000000000000 x21: 0x000000015cfe3200 x22: 0x000000019ba18014 x23: 0x0000000000000000 x24: 0x000000015cfe32a0 x25: 0x0000000000000003 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x000000015cfe3200 lr: 0x000000019b7da958 cpsr: 0x00000000a0000000

I have an iOS application that derives on UITextInput to enter text. I have also overridden pressesBegan() and pressesEnded() in order to have some extra keyboard management (auto-repeat, special actions for arrow keys, function keys...) That works well for single-character languages (most roman languages, such as English, French, etc). For multi-character languages (Chinese, Japanses, Korean, Hindi), I can detect that the keyboard has been set to that language, and switch back to the default version of pressesBegan(): if let keyboardLanguage = self.textInputMode?.primaryLanguage { if (keyboardLanguage.hasPrefix("hi") || keyboardLanguage.hasPrefix("zh") || keyboardLanguage.hasPrefix("ja") || keyboardLanguage.hasPrefix("ko")) { super.pressesBegan(presses, with: event) } } But that strategy fails with the Tiếng Việt Telex keyboard (for Vietnamese language input). The way that keyboard works (as you can see if you open a document in Pages) is that you type as you go: T-i-e-n-g V-i-e-t T-e-l-e-x and the system adds the relevant diacritics once you've finished a word, so typing "Tieng Viet Telex" gives you "Tiếng Việt Telex" on the screen. Is there any documentation on the inner workings of this specific keyboard? What should I do (or not do) in order to make my application compatible with Tiếng Việt Telex?