In my UI test I'm trying to set different languages. I noticed that with right-to-left languages, such as Arabic, the UI is still aligned left-to-right. When I manually run the app with the scheme's language set to Arabic, the UI is correctly aligned right-to-left. Am I missing something? let app = XCUIApplication() app.launchArguments += ["-AppleLanguages", "(ar)"] app.launch()

let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd" let localeIdentifier = "ar_AE" dateFormatter.locale = Locale(identifier: localeIdentifier) if let date = dateFormatter.date(from: "2022-12-26") {   dateFormatter.dateFormat = "dd MMM YYYY"   let displayDate = dateFormatter.string(from: date)   print(displayDate) // "26 ديسمبر 2023" } Converted date is one year ahead of the actual date. This issue occurs only with specific dates ranging from 26-Dec-2022 to 31st-Dec-2022, when Arabic locale is selected and on IOS 16.0 and above devices.

I am trying to get local times for an event, and I keep getting different time depending on the type of device I am running on, either simulator, or real device. The code: `do {       let placemarks = try await CLGeocoder().reverseGeocodeLocation(location)       if (placemarks.count) > 0 {         let localPlacemark = placemarks.first!         let timeZone = localPlacemark.timeZone!         let tzString = timeZone.abbreviation()         print("Time Zone for \(String(describing: localPlacemark.locality)) is \(tzString )")         return localPlacemark.locality ?? "Unknown Locale"       }       else {         print("Problem with the data received from geocoder")       }     }  On an iPhone 14, the timeZone.abbreviation I get (for the same location) is "EST". But on an iPhone 13, I get "GMT-5", same on an iPhone 8. All three are running iOS 16.2. Has anyone ever seen this? Also, since I am working with a full date during daylight savings time, on the 14 the time returned is correct (DST time), but "isDaylightSavingsTime" always returns false. This makes sense since the abbreviation is "EST" and not "EDT". However, the time returned is correct. On the iPhones 13 mini and 8, the time returned is Standard and not Daylight Savings. This is truly baffling. Any insights, suggestions or help are welcome! Thank you!!

iOS Mail app generates e-mail headers such as this: Cc: "Pop =?UTF-8?B?Wm9sdMOhbiI=?= <user@tld.com> RFC822 specifies how strings can be quoted with <"> = <ASCII quote mark> quoted-string = <"> *(qtext/quoted-pair) <"> RFC1342 specifies how non-ASCII text can be encoded encoded-word = "=" "?" charset "?" encoding "?" encoded-text "?" "=" encoded-text = 1*<Any printable ASCII character other than "?" or ; SPACE> (but see "Use of encoded-words in message ; headers", below) Although not explicitely prohibited by RFC1342, encoding the enclosing quote while not encoding the starting quote causes server-side SMTP processing to fail, if decoding is not performed before quote processing. IMO, quotes should NOT be encoded as per the intent of RFC822 to use the ASCII quote mark as delimiter.

Hello! I have a big complex application that struggles from a problem when a user presses Cmd+; shortcut on French AZERTY kb layout (the same physical keys as for Cmd+, on the default ABC layout), AppKit generates the following events: FlagsChanged for pressed Cmd modifier KeyDown with keycode=43 (comma), chars=";" KeyDown with keycode=53 (Esc) KeyUp with keycode=43 (comma), chars=";" FlagsChanged for released Cmd modifier I discovered that the Esc event comes from the internal method -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] which has a snippet of logic like the following: /* ... */ if ([event _matchesKeyEquivalent: [NSKeyboardShortcut localizedKeyEquivalentForInput:@"."] modifierMask:NSCommandKeyMask]) { /* explicitly send an Esc event instead */ } /* ... */ That looks unexpected, so my first question is why does such a logic exist there? Anyway, if there is such a logic in AppKit then I should observe the same behaviour in other AppKit apps, right? But a very simple application (which is essentially just an NSView which logs all keyboard events) doesn't receive an additional Esc event for the same keystroke on the same layout. The difference is that the internal AppKit call [NSKeyboardShortcut localizedKeyEquivalentForInput:@"."] returns @";" in case of my complex app but @"." in case of the simple one. And now I'm stuck trying to understand that difference, i.e. what could affect the behaviour of the [NSKeyboardShortcut localizedKeyEquivalentForInput:@"."] call since it's an internal AppKit call and there is no documentation for it and I don't know it's real semantic. Could anybody please advise smth? Thus, I would like to raise the following questions: What is real purpose of the AppKit logic expressed by the code snippet above? What can affect the behaviour of the [NSKeyboardShortcut localizedKeyEquivalentForInput:] call? What is its semantic? macOS SDK 12.3, if it matters.

I added a custom spelling dictionary (.aff, .diff) for the Armenian language because macOS doesn't have one by default. Enabled in the settings and restarted the computer. Spell checker only checks words longer than 10. I have tested same dictionary with Hunspell, it work perfectly. Problem is not new, it have on my all devices and friends devices too. Now I am using MacBook pro M2 with Ventura 13.2.1. I have several Armenian dictionaries to test. For example, you can try this: https://github.com/titoBouzout/Dictionaries

The error Bad Message 400 is on my iPhone screen when I try to access my country/ region. And I need change to download a app

In order to localize string interpolation inside SwiftUI Text Views, String(localized:) and AttributedString(localized:), the project or framework's build settings needs to have Use Compiler to Extract Swift Strings enabled (e.g. SWIFT_EMIT_LOC_STRINGS=YES). However, while testing exports it appears that exporting localizations (Product > Export Localizations) are always done using a RELEASE build rather than a DEBUG build. For us, this is problematic as release builds use certificates that are only used by the build system. Software or internationalization engineers trying to export localizations with Use Compiler to Extract Swift Strings enabled, will run into issues as the swift compiler step will fail. Is there a way to make localization exports use a DEBUG build rather than a RELEASE build? Or alternatively ignore signing for localization exports?

The MeasurementFormatter provides a string formatted in g/L when passed in a Measurement with unit .milligramsPerDeciliter. See example below. The same behavior happens for all unitStyles (.short, .medium, .long) and for .millimolesPerLiter. let formatter = MeasurementFormatter() formatter.unitStyle = .medium formatter.unitOptions = .providedUnit let concentrationMass = Measurement(value: 200, unit: UnitConcentrationMass.milligramsPerDeciliter) print(formatter.string(from: concentrationMass)) // Results in "2 g/L". Expected "200 mg/dL". Submitted bug with Feedback ID: 11934871

Hi, With iOS16, we have a new setting named Date Format in Language&Region menu. When I use setLocalizedDateFormatFromTemplate to format my date, changing Date Format setting does not update the format of my date. This is my code to format my date: let formatter = DateFormatter() formatter.setLocalizedDateFormatFromTemplate("ddMMyyyy") formatter.calendar = .autoupdatingCurrent formatter.locale = .autoupdatingCurrent formatter.timeZone = .autoupdatingCurrent let myText = formatter.string(from: Date()) I provided this template as an example. I have other templates like "dMMMMyyyy" or "dMMMM" and none of them gets updated when date format setting is changed.

I should preface my question by saying I love this formatter and the edge cases it handles for us, but I've found a case that seems odd to me. (all times are in the same time zone. let's go with Pacific) current time is 3:05pm, December 21 comparison time formatter output dec 20 @ 3:15pm 23 hours ago (great!) dec 20 @ 2:15pm yesterday (also great!) dec 19 @ 3:15pm yesterday (wait, wut?!) If today is Dec 21, shouldn't yesterday be limited to Dec 20 00:00:00 - 23:59:59? I see three options: I'm using RelativeDateTimeFormatter incorrectly I'm misunderstanding the sematics of 'yesterday' ( is it correct to refer to 47 hours ago as yesterday?) RelativeDateTimeFormatter is misbehaving all thoughts on this are welcome.foun here is some playground code demonstrating this behaviour let relativeDateFormatter: RelativeDateTimeFormatter = {     let formatter = RelativeDateTimeFormatter()     formatter.dateTimeStyle = .named     return formatter }() func startDate(from dateText: String) -&gt; Date {     let formatter = DateFormatter()     formatter.locale = Locale(identifier: "en_US_POSIX")     formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZ"     formatter.timeZone = .current     return formatter.date(from: dateText)! } let myNow = startDate(from: "2022-12-21T23:05:00Z") let almostTwoDaysAgo = myNow.addingTimeInterval(-(48 * 3600 - 600)) let relText = relativeDateFormatter.localizedString(for: almostTwoDaysAgo, relativeTo: myNow)

With iOS16, we have a new setting in the Language&Region settings menu that we can change the short format of the date. I have a text and to format it, when I use the old DateFormatter API with short dateStyle, after I change the date format in the settings menu, my text gets updated. However when I use the new iOS15 API with numerical DateStyle, it does not get updated. Here's the code. This one is the one working:(Old API): let formatter = DateFormatter() formatter.dateStyle = .short formatter.timeStyle = .none let myText = formatter.string(from: Date.now) This is the new API and it does not get updated when I change the date format in Languge&Region settings menu: let myText = Date.now.formatted(date: .numeric, time: .omitted)

When exporting localization in xCode for a shared framework, the localization build fails with the error "Could not choose a single platform from the supported platforms iphoneos, iphonesimulator, watchos, watchsimulator of target" Note that the shared target has multiple supported destinations = iPhone/iPad/Apple Watch.

My app has been live quite some time in the apple App Store. It has been installed by people from multiple countries. Today I got a report from a Canadian client that she could not find my app in the store. She was able to install it through a direct link to the app that was provided on my website though. To diagnose the problem I used a website to search for my app in certain "regions" of the app store, and I noticed I could find my app on the US app store, the Australian app store and the UK app store, but not on the Canadian one. US store - Correct result: https://fnd.io/#/us/search?mediaType=all&term=bookabooka Australian store - Correct result: https://fnd.io/#/au/search?mediaType=all&term=bookabooka British store - Correct result: https://fnd.io/#/gb/search?mediaType=all&term=bookabooka Canadian store - No result: https://fnd.io/#/ca/search?mediaType=all&term=bookabooka I double checked my appstoreconnect settings, and Canada is enabled as a target country / region so it should appear there as well. I went through the other settings of appstoreconnect, and found out that I had ONLY provided the localization for the app info in English (UK). There is a separate localization option for Canada, the U.S and Australia: English (Canada) English (U.S.) English (Australia) But since the app is visible on the U.S. and Australian versions of the app store this is probably not the reason. Any other ideas what could be causing this?

One of the possible values of the forecast property conditionCode is sleet. But according to wikipedia this term refers to multiple, quite different weather phenomena. Some harmless and other potentially hazardous. What type of weather does sleet refer to in the weatherKit API?

When I try to convert date to Arabic language with below code & ar_AE language code, it does not work. let dateFormatter = DateFormatter() dateFormatter.dateStyle = .medium dateFormatter.locale = Locale.init(identifier: "ar_AE") lblDate.text = dateFormatter.string(from: Date()) when we change the language code to _ar_OM_ or ar_SD or any other Arabic countries it works in iOS. let dateFormatter = DateFormatter() dateFormatter.dateStyle = .medium dateFormatter.locale = Locale.init(identifier: "ar_OM") lblDate.text = dateFormatter.string(from: Date()) Tested on iOS 15.5 & 13.3, there is nothing related to iOS version. Request someone to help me to understand the reason why "ar_AE" code is not working while if I provide identifier "ar" it works perfectly & that would be great help if we can resolve this.

Not getting thousand separator when the locale is changed. eg: Not getting 8.820 TRY(dot as thousand separator) when locale is changed to "tr-tr" or any other locale.

All but one of my app users are operating in the USA and are using it with no problems. I have one customer in Canada, with four users. They have had problems using the app from the start. However in the last month it will not open for them at all. While they can download the app from the Apple Store to attempt to reinstall, it will not open. Has something changed in the past few months that would cause this to happen?

when I'm trying to use SF Arabic on adobe XD I found that the letters which have dots are damaged especially when I change the thickness of the font which makes it impossible to use the font, how can I resolve this issue? also when I use the compressed and the extended font in SF pro how can I find the equalizing in SF Arabic?

DatePicker error is displayed when the locale supports RTL view. When I change the DatePicker style to inline style and change the default localization to ar (Arabic), the DatePicker shows number mirrors, after scrolling between months the display changes to the correct display but the day names are not associated with the day's numbers.