I put this in another reply, but should probably post it separately because it indicates to me that it’s possible it’s something with my client’s system in particular:
Terminal has nothing to do with our application and it’s giving the same security prompt. So it could be that any application on his system which tries to access the microphone gives this prompt. Or maybe some kind of virus that accesses the microphone (is this even a thing)?
Anyway, I guess the point is that it seems related to Xojo, especially because there are other reports of it happening when people switched to Ventura, but I can’t be absolutely sure that it’s a Xojo issue.
Perhaps voice control is on in Accessibility settings?
Thanks for the idea. I tried turning it on for my MacBook and running our application. It played the sound just fine without prompting for microphone access.
I think an app that is not code signed may display this warning. I could be wrong.
You were right! I just sent a code-signed app and, after resetting microphone security permissions, the code-signed version did not prompt for microphone access when playing the sound.
I still don’t understand why this did not happen on my machine, but for now it has solved the problem for us since users will only ever have a code-signed copy.
FWW I use NSSound (MBS plugins) and playing wav files is working without prompting anything (macOS Ventura).
I don’t think the sound.play does use NSSound on Mac so maybe that is using the microphone for some reason too.
BTW you are talking about OS X Ventura … that may be another OS that we are talking about
NSSound or Xojo Sound.Play() should not rise microphone alerts. I would like to see an experiment, sending a sample of an unsigned app playing a sound using NSSound to the guy whose microphone alerts arises when using Xojo’s Sound.play(). If the alert arises, there are clearly some new weird behavior associated to Ventura+signing+playing sounds+some machines (M1? Intel? Other condition?), if not, if NSSound works ok, Xojo Sound.play() is doing something wrong and needs fixing.
Can you, @ChristopheDV , provide such sample (if possible in a DMG) to @Mike_Gibson try such experiment?
I believe this was added in response to a very real hack on the macOS, where some USB cables not only contained a Wi-Fi modem, but also the ability to capture and send keystrokes, allowing a hacker to plug a device into your computer and take control, without you knowing.
Windows at least makes a notification sound when a USB device is plugged in, but the Mac remains silent.
So Christophe was mistaken about NSSound not firing a “microphone” alert to “play a sound”. MAYBE Apple implemented the “permission” for an ad-hoc signing on Ventura checking against the machine key where it was ad hoc signed behind the scenes not firing such alert there.
If this is true, removing the codesign and applying a new ad-hoc one on the target machine would eliminate such alert. something like this:
As I understand there’s different levels of permission for an app that’s downloaded vs somehow else got onto your machine. So it could be that compiling an app gives greater local freedom. I haven’t had time to look into it fully.
As I said, that’s my assumption. Ad-hoc signing may eliminate the “alert” in the machine where the ad-hoc signing was made, once the app is moved over another Ventura machine, it triggers there. So, a “possible” way of “fixing” false claims like “using microphone” to play sounds in ad-hoc signed apps, is removing the codesign and reapplying the ad-hoc signature on the target machine. Someone with enough Ventura machines could test my assumption.
If you’re using a recent version of Xojo (2022) the IDE automatically applies an ad-hoc signature to every app that you build now (the Sign step in the build target). That signature is only good on your machine.
It has been required for M1’s all along and Intel on recent versions of macOS.
I’m glad the mac stays silent. These Windows sounds that happen as soon as you plug a cable or do most things are annoying (my opinion, but a strong one).