@eskimo: Neither requires the full Accessibility privilege. That may be true under the hood, but while Listen access is (I think) reflected in System Settings > Privacy & Security > Input Monitoring, PostEvent access is shown as System Settings > Privacy & Security > Accessibility. Honestly, I think the best option there is to accept the quit and relaunch. It might be OK to repeatedly quit and relaunch while waiting for accessibility permission to be granted, but I wouldn't want to constantly be quitting and relaunching to detect the rare case of permission being revoked. Which was the OP's concern.

You don’t need ‘full’ accessibility access to listen for events. There’s a specific TCC service for that, namely ListenEvent. You can check where you have that privilege using CGPreflightListenEventAccess. Is there some reason that doesn’t work for you? In my case, I do need to post events as well as listen, and the original poster of this thread also indicates a need to do more than just listen. I'm aware that there is also a function CGPreflightPostEventAccess, but in my experience that does not update while my process is running.

The only reliable way I've found to detect accessibility access is to try creating a new event tap with kCGEventTapOptionDefault. If the permission is missing, CGEventTapCreate will return NULL. In my case I was dealing with keyboard events, not mouse events, but I expect it will work the same. Here's the code I use: bool EventListener::CanFilterEvents() { CFMachPortRef thePort = CGEventTapCreate( kCGSessionEventTap, kCGTailAppendEventTap, kCGEventTapOptionDefault, // active filter, not passive listener CGEventMaskBit(kCGEventKeyDown), CTapListener::MyTapCallback, NULL ); bool madeTap = (thePort != NULL); if (madeTap) { CFMachPortInvalidate( thePort ); CFRelease( thePort ); } return madeTap; }

It's conceivable that System Settings > Privacy & Security > Accessibility could be needed. Try calling CGRequestListenEventAccess, which may result in a prompt to add some permission in System Settings.

Yes, CGEventSourceKeyState. You need to use the virtual key codes, not character codes. The Carbon header file Events.h contains enumerated constants for these codes.

Well, the obvious thing to do is open Feedback Assistant and send Apple a bug report.

I’d appreciate you filing a bug about Xcode requesting that. OK: FB12585357

Xcode 14.3.1, too. It turns out that the issue was that my team leader had not yet agreed to an update in the developer program terms. Aargh! Couldn't there be a clear error message in that case?

If you log in to your account at developer.apple.com, does it say that there is a program license agreement that you haven't agreed to yet? Sometimes you get totally cryptic errors in that situation.

Yes, I think that "suggestion" would apply to both user-visible features and API features.

Me too. macOS Ventura, Xcode 14.0. One time I got a crash from a process named com.apple.dt.Xcode.ITunesSoftwareService. Tried again with Xcode 14.3, same result. Tried with Xcode 15 beta 2, and Xcode completely crashed.

How did you create new developer certificates? I'm not sure how you could create a certificate without creating a private key. The way I would create a new developer certificate is within Xcode: In the settings dialog, select the Accounts tab. Select an account, and then click the "Manage Certificates..." button. When a signing certificates window pops up, use the "+" button in the lower left corner to make a new one. The certificate and its private key should then appear in your default keychain.

I failed to mention that I'm getting that message about Apple Event entitlement for both the main app and the helper. What API are you using to register your login item? -[SMAppService registerAndReturnError:] Which process is crashing with the launch constraint violation? Now that you asked, I took a closer look at the crash report, and saw that what was crashing was the login item from a different build of my product. D'oh! I suppose it's something about the code signing being different. I had an App Store build installed, but for testing an update I was using a notarized build. Once I removed the old version, the crash stopped happening. However I still see the warning about Apple Events entitlements for both the main app and the login item.

I think what you're looking for is the "macOS deployment target" build setting. In Xcode 14.3, the deployment target can be set as far back as 10.13. Don't worry about the "platform" setting.

Have you read the documentation on SQLite temporary files at https://www.sqlite.org/tempfiles.html? It seems self contradictory. Section 2.1 says that a rollback journal is in the same directory as the database file, while section 5 says that temporary files are elsewhere. Are you getting an error message telling you the path of the file that can't be opened?