I was referring to Privacy & Security > Input Monitoring. Yeah, we're kind of talking past each other here. Input Monitoring is what you'd be looking at if you used CGRequestListenEventAccess, but in the case of CGRequestPostEventAccess, it's Privacy & Security > Accessibility.

This is not an installer package, so you should not be passing -t install to spctl.

Right. That’s why, when you change these values in System Settings, it offers to quit and relaunch the app. I just tried toggling a couple of the Privacy & Security > Accessibility switches, and it did not offer to quit and relaunch the apps. Anyway, that's why I said that I preferred using CGEventTapCreate, that allows me to detect a change in the permission without a relaunch.

If you want to make a feature request, please use Feedback Assistant (the app, not the forum tag). By the way, you say parenthesis and bracket, but the image shows braces. Those are 3 different things.

Quinn, when I said I have an “active” tap, I meant I need to be able to post events. I was aware of CGPreflightPostEventAccess and CGRequestPostEventAccess (probably heard about them in one of your other posts). (The Settings app displays that access as accessibility trust, though it may not be quite the same internally.) But in my experience, they don’t change their results “live”. That is, if I get a false result from CGPreflightPostEventAccess, then while my app runs, go to Settings and grant the permission, then go back to my app and check the result, it’s still false.

I have an app that needs accessibility trust to install an active global event tap. The only way I found to reliably detect whether I have that trust is to just try calling CGEventTapCreate and see whether it returns NULL or not.

Go to the download area of developer.apple.com and click the More link.

If you select the field and then look at the size inspector, what does it say next to Layout, "Autoresizing Mask" or "Inferred (Autoresizing Mask)"? In my experience, if I set all my items to "Autoresizing Mask", then Xcode won't bug me about constraints.

By the way, experimentally, Finder won't let me set a file name with more than 255 (ascii) characters on an APFS volume. But maybe that's just Finder, not the file system.

One of the references of the Wikipedia article is the Apple File System Reference . It’s pretty technical, but as far as I can tell, the name of an APFS volume is stored in 256 bytes, but the name of a file is a null terminated string, and elsewhere the name of the string is stored as a 10 bit unsigned number.

Whoops, never mind! I needed to set com.apple.security.inherit to true in the entitlements. Now I see more documentation: Embedding a command-line tool in a sandboxed app

Go to the downloads area at developer.apple.com, click the More link, and you'll find it in the list. I can't promise that it will run on a recent version of macOS.

The frontmostApplication property of the NSWorkspace class can be observed with key-value observing (KVO).

I tried your project and it does reproduce. I notice that I don't see the glitch if I increase the step parameters to CGPatternCreate, putting gaps between the cells. You should send a bug report with Feedback Assistant. This forum is not an official channel for reporting bugs. By the way, you can simplify your code sample a bit. Instead of passing the size as a dictionary, pass &_size in the CGPatternCreate call, and then say CGFloat size = *(CGFloat*) info; in the callback.

You do need to notarize your app. Otherwise users will not be able to start it the first time.