[Addendum] I have worked around it for the time being, as below, but this is fugly... # if XCODE_WORKAROUND_ENUMS # define E3_SMIME_COMPRESSED_DATA (0) # define E3_SMIME_ENVELOPED_DATA (1) # define E3_SMIME_SIGNED_DATA (2) # define E3_SMIME_CERTS_ONLY (3) # define E3_SMIME_UNKNOWN (4) # define E3SMimeType int # else typedef enum { E3_SMIME_COMPRESSED_DATA, // Compressed data E3_SMIME_ENVELOPED_DATA, // Enveloped data E3_SMIME_SIGNED_DATA, // Signed data E3_SMIME_CERTS_ONLY, // Only certificate data E3_SMIME_UNKNOWN, // Que ? } E3SMimeType; # endif

Thanks - there's no profiles, I checked anyway but this is my own machine, and I wouldn't install anything that wanted to enable "management" like that. Disk Utility couldn't find anything wrong with the disk, so I'm in the middle of triggering a Time Machine backup before going for the nuclear option of reinstalling the OS. As it turns out, I could use the older Xcode (the one the App Store would let me download for 15.4.1) on the MBP to work with the project I'd been working on the Studio with, so no real problem this time around - still not really sure why the MBP OS is being stubborn though. Thanks again :)

Thanks Quinn. For storing an encrypted key, it looks as though a private keychain access-group might work as well - so maybe a combination of the container and encryption would be sufficient.

The goal here is to support end-to-end encryption of messages between devices. There's not much point in having E2E encryption if anything can just read the content locally :) - even if the user has to specify they can do it. Social engineering is something of an art form these days... I could encrypt the data, but then the question becomes 'where do you keep the master encryption key'. For a launch-agent to be the gatekeeper, I don't really want the user to have to type in a password before it can read its data, neither do I want it to be dependent on network access to pull a key down from secure storage in the cloud. If the encryption key is stored in the keychain, then anything can access that key, so ... It's just sort of frustrating to know that it can be done based on an entitlement (for example: Mail.app does exactly this) but it's not available to mere mortals ... Thanks for the hint on the XPC/sandboxing - I'll check that out. I thought I'd done XPC with a sandboxed app before, but that was a few years ago, and things do change...

Hi :) The context is a cross-platform email application. Text can arrive encoded in any one of a large number of encodings, and similarly be sent out in the encoding that the recipient has deemed as the preferred encoding. Because it's cross-platform, I'm using iconv (shipped by default on the Mac) to do the test for "can we decode this format to something the local platform can display", and similarly in reverse. The iconv call requires a 'from' and 'to' encoding specification. Depending on direction, the "local default" encoding spec is what I'm trying to find with the above. Now I could just say "It's a Mac, we'll use UTF-8", but every other platform responds to either the nl_langinfo() call, or at least one of the environment variables are set. Seems odd that the platform I'm developing it on is the one that doesn't provide the API :) Having said all that... On the Mac, the design for the email app is going to closely follow that of Mail.app - where there's a LaunchAgent that handles all the background stuff and is the only thing with permission to actually read email content. The application (iOS or MacOS) will interact with the launchAgent over XPC, and if the launchAgent has a "Terminal.app" kind of environment rather than the restricted one I see for Applications, I could obtain the LANG variable contents after launching the app, via an XPC call.