No Microphone access in development (Xcode cmd-r) builds

I maintain an audio editing application and I recently noticed that the debug builds I run during development (the most plain ones you get by pressing CMD B or CMD R in Xcode) don't get access to the microphone. You don't get any error message or dialog box asking for permission - the audio input is just a bunch of 0.0s.


My fully signed (for distribution, either developer id or mac app store) builds have no problems with that. They can record fine.


Now this is very annoying when I try to do actual development work. I cant sign & export a build every time I try to test something.


So, what kind of user error am I making here? Do I need to set up some fancy development provisioning certificate to get this working? I tried removing the (release build) applications from the Security & Privacy "access to microphone" panel to maybe re-set the permissions dialog. But I don't see how. There's no remove option, only unchecking the checkbox. Which, as expected, just nulls the audio input.


/edit: Running Mojave 10.14, Xcode 10.0 (all release, no beta) - recording device is built-in MacBook Pro microphone. (The device does work fine).

Replies

use `tccutil reset Microphone` (the capital M is important!) to reset the user granted microphone permissions. then the xcode built version should ask you for permission again.

  • Thank you. This worked for me.

Add a Comment

This did NOT work for me. All it did was remove all the applications I gave access to from the Security & Privacy Microphone preferences.

There seems to be two issues here: microphone access for both Xcode and the app itself.


Your app (or a UITest) can prompt (fail) for either or both, though not always on same run.


Both of these dialogs must be approved to allow access, after which the permission persists between Xcode and Simulator resets or restarts.

You can confirm access has been approved for Xcode in System Preferences -> Security & Privacy-> Microphone, where you should see the Xcode in the UI.


The app itself, approved or not, won't appear in the UI here, however.


If you are unsure it the app has been approved, reset all the microphone permissions with 'tccutil reset Microphone' in the Terminal, and re-run your app/test, until both dialogs have been shown and approved.

This didnt work for me. I am runint tests with xcodebuild for my app, and event though I granted access for a given simulator on a first run (where the tests succeded) on a second run I must grant access again, even if I am using the same simulator. Any clues??

If this is reproducable, then all of you should submit bug reports (see Report Bugs link below). Perhaps the Mohave sand-box security team and the Xcode team didn't talk to each other about this development scenario, and re-built debug builds are locked out.

I had the same problem and the issue is that in order to get the popup dialog asking for microphone access, you must have the NSMicrophoneUsageDescription key in the Info.plist. It seems that if you don't have this, then the XCode debugger still allows the app to run but of course there is no access to the microphone so only zeros are returned.


If you run the executable from the terminal, then the microphone access dialog is prompted for by the Terminal.


If you run the app itself (eg from the Finder) it crashes if you don't have NSMicrophoneUsageDescription in the Info.plist.


You can make the dialog appear at an arbitrary time (ie before the microphone access is really required) by using the

AVCaptureDevice.RequestAccessForMediaType Method


https://developer.apple.com/documentation/avfoundation/avcapturedevice/1624584-requestaccessformediatype

Thank you, this really helped me. Especially since in system settings, the simulator does not appear in the list of apps requiring microphone acces.

The problem is that the internal microphone for your mac(book) is not recognized inside the simulator (for reason i am still debugging). If you attach an external microphone and then in simulator go to i/o -> Audio input and set it to a different input device, it should work fine.