Hi folks, I’m just holding out my alms-cup here, as it were, because I couldn’t get an answer from Stack Overflow or Perplexity AI.
I’m writing C++ on macOS (Sequoia 15.0.1) and using XCode 16. I’m using the SFML (2.6.1) library and my programs need to use functions that control the mouse cursor or query the realtime state of the keyboard. MacOS is set up to require permissions being granted to the application to use those features. Setting the permissions in the Privacy & Security settings tab the first time is not a problem, but I understand that these permissions are supposed to persist across builds, and that is not what is happening.
Every time I make a one-character tweak to the source code and build/run afresh, the game doesn’t respond to the keyboard.
Please tell me there’s some setting (in XCode, perhaps, about identifying the app or bundle? I believe I used the Command Line Tool template to originally start the project…) that will cause the OS to recognize successive builds as having mouse and keyboard permissions!
For the most part, this has only been an issue since I made a big switch from:
2017 MacBook Air to 2023 MacBook Pro
MacOS 10.14 Mojave to MacOS 15 Sequoia
XCode 10.1 to XCode 16
SFML 2.5.1 to 2.6.1
However, even in the old setup I had a permissions issue in the single instance of trying to move the cursor by fiat to a new location. But never any keyboard issues.
My XCode workspace projects were all created under the earlier setup. I’ve also set a custom working directory in the scheme, because otherwise it doesn’t seem to be possible to use relative paths for loading resource files.
It’s not even a matter of flicking to the Privacy tab and toggling a little blue switch. I have to delete the game from the list of apps with permissions, then click the plus sign and navigate through the filesystem hierarchy to find the app and reapprove the new build of it. I have a dozen and more substantial projects that all make use of SMFL keyboard and mouse functions, and going through this rigmarole after every single code tweak is absolutely prohibitive to getting anywhere.
Alms, alms for the poor!?
@zarf I hope you don’t mind if I ping you, as you’ve imparted C++/Mac/permissions related knowledge in the past…
It’s possible that I’ve got some light here; the bundle identifier may have not been properly set on the project I was dealing with. When I get time I’ll do some more testing and check my other SFML projects to see if I’ve really solved the issue…
You mentioned going on forums, but have you tried using ChatGPT? I find that even when it doesn’t know the answer, it provides a thorough checklist on the basics and specific keywords to follow up on. I pasted a portion of your C++ problem into ChatGPT and this is what is spat out…
ChatGPT Summary (click to expand)
The issue you’re experiencing with permissions in macOS for your SFML application is related to how macOS handles app entitlements and permissions. When you build your application from Xcode, it generates a new app bundle each time, which can cause the system to treat it as a different application, hence losing the previously granted permissions.
Here are some steps to help you maintain the necessary permissions across builds:
1. Ensure Consistent Bundle Identifier
Make sure you have a consistent bundle identifier for your application. You can set this in Xcode:
Select your project in the Project Navigator.
In the project settings, go to the General tab.
Look for Bundle Identifier under the Identity section. Ensure this is set to a unique string (e.g., com.yourname.yourapp).
2. Set App Sandbox Entitlements
If your application is sandboxed (which is common for apps on macOS), you need to enable the appropriate entitlements:
In the project navigator, select your project, then go to the Signing & Capabilities tab.
Click on the + Capability button and add App Sandbox.
Make sure to enable the necessary permissions under the App Sandbox settings, such as Input Monitoring for keyboard and mouse events.
3. Use a Persistent Application Identifier
If you’re still having issues, consider using a persistent application identifier. You can do this by following these steps:
Open the Terminal and navigate to the directory where your app bundle is built (e.g., ~/Library/Developer/Xcode/DerivedData/YourAppName/Build/Products/Debug).
Use codesign to sign your app manually, ensuring macOS recognizes it as the same application each time.
codesign --force --deep --sign - YourAppName.app
This tells macOS to treat this app as the same application, thus preserving permissions.
4. Re-grant Permissions Manually
If necessary, you can also manually re-grant permissions for your app after each build:
Go to System Preferences > Security & Privacy > Privacy tab.
Select Input Monitoring and add your application again if it’s missing.
5. Check Console for Errors
If issues persist, check the Console application for any error messages related to permissions when you run your app. This can provide insight into what might be going wrong.
Summary
By ensuring a consistent bundle identifier and managing entitlements correctly, you should be able to maintain the required permissions across builds. If the problem continues, consider looking into the code signing process or manually re-adding permissions as a workaround.
I should mention that I have no idea about your problem. Just spitballin’ here.
I appreciate it! I didn’t use ChatGPT but Perplexity does more or less the same thing.
I was super hopeful when I saw the tip about codesign, but unfortunately that didn’t fix it either! I’m pretty certain my bundle identifier is filled and unchanging. I’m pretty certain my project isn’t using sandboxing. So confusing! This seems like it should be a fundamental issue, allowing a developer to control the keyboard and mouse without this kind of hair-pulling.
This wouldn’t have anything to do with my SFML library binaries being stored in /usr/local, would it? My TADS libraries had some (different) weird behavior when stored there, till I moved them to a subdirectory of my User home folder.
I’ll probably do that!
Permissions across builds were a problem even on my '17 Mac with Mojave, but in that case it was only certain mouse functions and not keyboard.
I’m certain there’s a way to make it work, but it’s rather frustrating that it’s so obscure!
Happy news! By sifting through some other Stack Overflow material and Xcode docs, I arrived at a configuration of settings that seems to allow me to rebuild without having to open the permissions panel every time.
It involved accounts, entitlements, and code signing settings which frankly seem more abstruse than the objective calls for…
I don’t expect you to do a full write-up of this, but would it be possible to give some pointers to the information that helped you solve it? It sounds like the kind of problem that I will run into sooner or later.
Happily!
It seems that the actual permissions required can vary between MacOS versions (as mentioned, Mojave only gave me trouble with certain mouse permissions, where Sequoia is (was?) giving me fits when I try to query the real-time state of the keyboard (SFML’s isKeyPressed)), but hopefully the “fixing” process is about the same.
In short, the solution revolved around proper signing, but it wasn’t exactly obvious how to achieve the desired setup for a hack like me that’s not already part of a development team with officially issued certificates.
Here’s what I did:
In Xcode menu choose Settings.
In Settings choose Accounts tab.
If you haven’t added your Apple ID to the list, click the “+” and do so. You should now have selected a “team” that looks like `My Name (Personal Team).
Then go to the “Signing and Capabilities” tab (which appears in the tab set along with “Build Settings” and “Build Phases” etc.)
Now make sure that “Team” is set to “My Name (Personal Team)”, make sure your bundle identifier is filled out uniquely, and make sure that “Signing Certificate” is set to “Developer”, and not “Sign to Run Locally”.
Somewhere in the process you should end up with a “MyProject.entitlements” file.
Make sure that after all the rigmarole you build afresh, and go one last time to the Security/Privacy tab of System Settings. In my case, the Input Monitoring section was what was applicable, but I believe the Accessibility section might be involved for mouse stuff. In either case, delete your executable from the existing list of permissions, click “+” again, find your app/executable, and add it one last time.
With this settings combo I was able to stop the continual permissions lockouts after every code tweak. If the process is any different for other IDE’s besides Xcode I wouldn’t know!
Hoping that this successful behavior will be reproduced as I continue to go through my Xcode projects and update the settings and associated source code (filename paths etc.) to work on my new ARM laptop.
