Hi @eskimo, thank you for your help, is now clear to us! Have a good day!

Hi @eskimo, it seems this solution Bundle.main gets you application bundle. preferredLocalizations is a list of languages your application bundle supports in user-preferred order. The first element will be the language your application is running in. is not working as expected, is returning English everytime because English is the first element, even if application language is French, for example. Here is the source code, could you please take a look at it? Not sure if we are doing something wrong or there is something wrong in the CoreFoundation side. Many thanks for your help! CFArrayRef cfAllLanguages = CFBundleCopyBundleLocalizations(cfBundle) CFArrayRef cfPrefLang = CFBundleCopyPreferredLocalizationsFromArray(cfAllLanguages); --- this should return language of the application but it returns En each time CFArrayRef cfLocalPrefLang = CFBundleCopyLocalizationsForPreferences(cfAllLanguages,cfPrefLang); CFArrayRef cfDefaultLang = CFBundleCopyLocalizationsForPreferences(cfAllLanguages,NULL); CFStringRef lss = (CFStringRef)CFArrayGetValueAtIndex(cfAllLanguages, 0); Thank you!

I see, thank you @eskimo for the help!

Thank you, guys, for your answers. @eskimo we are running an application and we would like to know the language of another application, independent of our application. This application might be running or not. We are targeting Apple x64 machines, both ARM64 and Intel processors.

Thank you for all the information, Eskimo!

No, our program is not failing. It is working as expected. Understood, thanks for the recommendation. We will most likely go with this approach, but is there any way to find the source of this message? I am thinking it is coming from a 3rd party library or maybe a macOS Framework. Thanks again!

Hi, sorry for this late reply. Thanks for you answer, I will try to reproduce it using Network Link Conditioner. Thanks again!

It seems our customer is not using internet connection at all, when our application is calling dlopen. Do you think this could be the cause?

Thanks for your help, we will ask our customer to perform the test. The issue is reproducing only on customer environment, we couldn't reproduce it on our own. One thing to mention is that the dynamic libraries are signed and notarized with a different certificate than the Application that is loading them. Hardened Runtime is enabled. Hope this is helpful information. Thanks again! LATER UPDATE: we are also seeing delays of about 4-7 seconds when checking signature of dynamic libraries

By "first load" I mean when dlopen is called for the first time (when the application starts) for the respective library. After a few seconds dlopen is called again for the same library but this time is returning immediately. This is normal because the library is already loaded in the process memory. The delay comes back if I restart the machine, rebuild the library and/or quit the loading process. Basically everytime the application starts, the delay comes back.