Hello, I would like to know if there is any way to programmatically find out the current language of an application(either budle info, plist,any function from CoreFoundation, etc ). Only information I found relating to this is in CFBundleDevelopmentRegion from plist of the app but its not reliable in all cases. We are coding in C++ but we can also run Objective-C code. Thank you in advance!

Hello, Our application is logging sometimes the following message: 2020-11-18 09:47:12.937916+0200 OESIS-V4-SampleApp[1330:45664] [Metadata] ==== XPC handleXPCMessage XPCERRORCONNECTION_INVALID This is all the information that I have, if I use breakpoints to narrow down the possibilities, the error is not showing anymore. Any debugging advice/starting point would be great. Our application is offline, so we are not using XPC services. And is written in C++ but has dependecy to some macOS Frameworks. Thanks in advance!

Hello, I have the 'libTestlib.dylib' which has Linked Dependency to CoreServices.framework If I call dlopen(libTestlib.dylib), library is loaded successfully. Also CoreServices.framework are loaded even if I do not have any piece of code that uses this framework. After dlclose(libTestlib), CoreServices.framework is still in the process memory (OS failed to unload it) causing our test library to also still be in the process memory. If we remove CoreServices.framework from Linked Dependency, the issue is not reproducing anymore. Also, if we comment std::stringstream from our code, the issue is not reproducing. It seems there are some issues with std::stringstream and CoreServices.framework together (maybe CFString?, maybe LLVM? ). Could you please help on this case and provide a solution on why the CoreServices.framework (and our test library also) is still loaded in the process memory after dlclose? I have attached both xcode projects, 'libTestlib' and 'SampleApp'. Also, the 'Reproduction' folder contains the already built targets, to reproduce the issue just run cd "...../Reproduction" ./SampleApp The output will show the open libraries before and after dlopen call and after dlclose call. You can see that CoreServices.framework is still there after the dlclose(libTestlib). Many thanks in advance for your help!! Here are the xcode projects: I cannot attach the sample projects so please advise how to attach them

Hello, we have encountered delays of ~35 seconds when loading some of our internal libraries (*.dylib files) using dlopen. The libraries are codesigned. Only the first load of the library is taking 35 seconds. The next dlopen calls (for the same library) are taking a few ms. We encountered the issue on macOS Mojave 10.14.6 and macOS Catalin 10.15. We are calling dlopen in these two versions: dlopen(library, RTLDNOW) dlopen( library, RTLDLAZY | RTLD_GLOBAL ) Please let us know if you experienced the issue and if there is a solution to this. Many thanks in advance