Can anyone tell me what these messages mean? We are seeing them sporadically: 2022-06-18 14:30:20.094 java[58370:18583094] XType: com.apple.fonts is not accessible. 2022-06-18 14:30:20.095 java[58370:18583094] XType: XTFontStaticRegistry is enabled.

I submitted a bug report for this, but posting here as well hoping for some answers. There is a bug in macOS 10.15 (specifically, I am using 10.15.5) in which a privacy access dialog appears when debugging an executable in lldb. Expected behavior: When debugging an app that lives in the Desktop folder, the process runs as expected without any privacy dialogs appearing. Therefore, we expect the same behavior when debugging regular (non-app) C++ executables; i.e. when debugging the executable, no privacy dialogs should appear Actual behavior: When debugging a plain C++ executable that lives in the Desktop folder, a privacy dialog to appear appears when the process starts, prompting for access to the Desktop folder This is unexpected and frustrating because it also prevents us from being able to debug executables through ssh (reported in FB7778150)

I submitted a bug report for this, but posting here as well hoping for some answers. There is a regression in macOS 11 in which TCC automatically denies privacy access by default when an executable is run from the lldb debugger, if the executable needs privacy access for folders like Desktop. Expected behavior: In macOS 10.15, building an executable that lives in the Desktop folder and running it in the debugger causes a privacy dialog to appear, prompting for access to the Desktop folder This is expected because hash is regenerated with every build Actual behavior: However, in macOS 11, the behavior has changed - instead of a privacy dialog appearing, no dialog appears, and privacy access is immediately denied by default. When run from the Desktop, the executable fails to run with the error “file system sandbox blocked open()”. However, if the executable is compiled and run from the /tmp directory, the executable runs normally without error, although we don’t get a privacy dialog like we do in macOS 10.15.   This is unexpected, and the only workaround is to give the executable Full Disk Access. The workaround is not feasible for us, because we are constantly building unit test executables, along with our main application executable (built outside Xcode), in network areas (so they require access to a network volume), and can’t possibly give full disk access for each one every time it gets rebuilt.  This is reproducible in a simple C++ executable - attached to this question is the contents of a makefile that generates an executable and starts it in the debugger: Standalone test executable makefile - https://developer.apple.com/forums/content/attachment/03194f79-5cab-4041-b8de-160dbb3756cd The relevant entries in the unified system log for TCC say stuff like " Refusing authorization [...] without NSDesktopFolderUsageDescription key". This indicates that access is being automatically denied because there is no key. However, this is an executable, not an app bundle, and it therefore does not have an Info.plist file. In addition, this issue did not occur in 10.15, and I don't see any release notes that mention something changing.

In our app, we allow the user to open files using the native NSOpenPanel API. In the open dialog, we have an accessory view to filter the set of enabled files based on file type. The first filter in the list (i.e. the default filter), is "all <appname> files", and last filter in the list is "All Files".  In macOS 10.14 and earlier, switching to the "All Files" filter successfully enabled all files, even ones not categorized as "<appname> files". However, starting with macOS 10.15, this no longer works as expected - switching to the "All Files" filter only enables files considered "<appname> files". After investigation and debugging, we determined that setting the initial filter to "All Files" produced the expected results, giving us the following conclusion:  In 10.15, a file will only appear enabled in the dialog BOTH of the following are true: shouldEnableURL returns true for the file The file belongs to the set of valid items in the initial filter In other words: In 10.14, shouldEnableURL was the only thing that determined whether or not a file should appear enabled In 10.15, an additional factor is now involved (checking against the initial filter set) As you can see, we ultimately do not have overall control over which files will appear enabled. The only thing we pass to the OS is shouldEnableURL, so it seems the OS is caching the filter after it is initially set. Even though making "All Files" the initial filter solves the problem, it is a last resort fix due to various reasons, and isn't ideal for us. Is there a workaround?

Starting in macOS 10.15/Xcode 11, I am seeing the following messages appear when running my app through its command-line entry point: CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug. CoreText note: Client requested name ".SFNS-Bold", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. CoreText note: Client requested name ".SFNS-Bold", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. I have confirmed that this is coming from Java (which I depend on), so I can't fix it. For me, this warning is benign, but could affect parsing of our test system, and is jarring to the user. Is there any way to suppress these messages in my app? For example, maybe a user default I can set?

My application requires access to the Documents folder. As a result, the first time you launch the app, you get the privacy dialog that prompts you to give the application access to the Documents folder. If you hit OK, the checkbox appears enabled in privacy preferences.  However, if I then uncheck that box and launch my app again, it gets killed right away. The system logs show access is denied for kTCCServiceSystemPolicyDocumentsFolder. This feels unexpected to me, because if the checkbox for Documents folder isn’t checked, shouldn’t things revert back to the original behavior, where the user is prompted for access?  To summarize: Expected behavior: Disabling access to Documents folder in privacy preferences and then launching the app should result in the privacy dialog appearing to request access from the user Actual behavior: Disabling access to Documents folder in privacy preferences and then launching the app causes a SIGKILL to get sent to the app, so the app fails to launch without any user-facing error messages. In addition, if I remove all entries for the app in “Files and Folders” and “Full Disk Access” (in an attempt to revert back to the original prompting behavior), the same issue occurs.  Is the behavior I am seeing by design? I realize I can manually reset the TCC database but would like to know if the behavior I am seeing is intentional or not.