My client and I are both using Xojo 2022r3.1 and OS X Ventura.
On his system he is getting the following prompt when the application tries to play a sound:
“[Application] would like to access the microphone”
This is just a simple sound file, success.wav, that was dragged into the IDE. The app uses success.play() to make it play. No microphone access is ever needed or requested.
However, I cannot replicate it on my own MacBook Pro (also Ventura and Xojo 2022r31). I have checked the security preferences to make sure it isn’t already authorized for microphone access, and it’s not.
Has anyone else experienced this? Any workarounds?
Thank you!
Edit: This is the only related forum post I could find but it was during a Ventura test version and there wasn’t really ever a resolution: Is it too early to test Ventura?
I don’t know what’s happening, only guessing. Maybe the target device has both input and output capabilities and the driver calls both when initialising?
What if your user selects a different sound output in System Preferences/System settings? Does the message also appears?
Ah, so you think maybe it could be that something like a bluetooth headset is in use and in order to output sound to that it is also asking for microphone access because they are both wrapped into the same device?
If so, that might explain why it’s only happening on his end. I will ask about that, thank you!
That’s my guess (or the driver that is badly written), but just an idea.
My suggestion is what I would have tried to narrow the problem down (try with another output). If it works there, it’s a problem with the first output; otherwise, we know it’s not a problem about the output, but rather a software issue.
Entitlements and permissions are not dependent of codesigning. Codesigning is just an integrity check to assure that your app has not got modified by anyone after you released it. An unsigned app is just an app without such check. It SHOULD not interfere.
Tell that Apple - pretty please. My app needs Full Disk Access to work properly. Even in the debugger I need to codesign fully or Full Disk Access doesn’t work. The adhoc codesign is not enough.
Full disk access is a very privileged administrative permission. Very few apps should have it because they will be able to break the system. That’s kind of root access. Sysadmins does not allow root access to users, if they do, they need to know the guy, that’s why they block you until they know you (Codesign? Notarize?). Microphone access to play sounds is some glitch, AFAIK can’t be circumvented with plists or codesigning. The only plist key I know for microphone access is one that contains a string to show to the user explaining WHY your app is trying to access the microphone. Ventura is really saying that Mike’s app is trying to access it, wrongly (Ventura bug?) or not (something is intercepting the microphone on such machine when mike’s app is running and blaming his app).
The only reason I’m assuming this is because in my testing of this exact sound permission issue, the test app available at the issue (https://tracker.xojo.com/xojoinc/xojo/-/issues/69631) consistently reproduces the problem. However my own app, once code signed, no longer reproduces it. There could be another factor as I haven’t run further tests.
My suggestion is what I would have tried to narrow the problem down (try with another output). If it works there, it’s a problem with the first output; otherwise, we know it’s not a problem about the output, but rather a software issue.
So it turns out his device is a standard MacBook with no other devices, standard speakers as output. There is a screen recording program listed in output but it is not currently selected.
And additionally I got this bit of information that the same prompt is coming from our application and from Terminal:
To add to the weirdness, this afternoon when I opened Terminal it said “Terminal want to access the microphone” with “Don’t Allow” and “OK”. That makes absolutely no sense.
Usually, an entry in the plist file solve the trouble.
We have no plist entry related to audio. But we have never needed one before, and the plists would be the same on both Macs (mine and my client’s) so I would not expect only one to prompt for Microphone Access when playing a sound, right?
However my own app, once code signed, no longer reproduces it. There could be another factor as I haven’t run further tests.
To test this theory we will code-sign the app to see if it still prompts. I will post the results later. If code-signing solves it then that would fix our problem.
My client has been not allowing the permission, and then removing it to reset. It always appears right when the sound tries to play, which is prompted by user action, not at application launch.
