The app's Info.plist must contain an NSMicrophoneUsageDescription key with a string value explaining to the user how the app uses this data

For the lazy:

if you want to quickly add usageDescriptions for most media access (on-device photos, camera, video recording, location):

right click your info.plist file and -> open as -> Source Code

then paste the following between the current values:

<key>NSMicrophoneUsageDescription</key>
<string>Need microphone access for uploading videos</string>
<key>NSCameraUsageDescription</key>
<string>Need camera access for uploading images</string>
<key>NSLocationUsageDescription</key>
<string>Need location access for updating nearby friends</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>This app will use your location to show cool stuffs near you.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Need photo library access for uploading images</string>

These descriptions, of course, are up to you. I tried to make them as generic as possible.

Hope this saves someone's time!


Just add NSMicrophoneUsageDescription key & in value add the justification that why your app is using Microphone. This is the latest requirement in iOS 10.


And the culprit was (drums) : Instabug framework. They tell you right there on their marketware pages they allow users to take audio notes during feedback composition. So I've added NSMicrophoneUsageDescription into the app plist explaining that.

Note that there is a lot of apple API that instabug uses

Undefined symbols for architecture arm64: (i've removed some that seems legitimate according to what that framework claims to do and left what I see no claims for in the marketware)

"_AVMakeRectWithAspectRatioInsideRect", referenced from: +[IBGIAMImageAttachmentView sizeForContent:forWidth:] in InstabugHost_lto.o

"_OBJC_CLASS_$_CTTelephonyNetworkInfo", referenced from: objc-class-ref in InstabugHost_lto.o

"_AVNumberOfChannelsKey", referenced from: -[IBGVoiceNoteManager startRecording] in InstabugHost_lto.o

"_CTRadioAccessTechnologyHSDPA", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyGPRS", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyWCDMA", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyEdge", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMA1x", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMAEVDORevA", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMAEVDORevB", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyLTE", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_OBJC_CLASS_$_AVURLAsset", referenced from: _OBJC_CLASS_$_IBGAsset in InstabugHost_lto.o

"_OBJC_METACLASS_$_AVURLAsset", referenced from: _OBJC_METACLASS_$_IBGAsset in InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMAEVDORev0", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

"_CTRadioAccessTechnologyHSUPA", referenced from: +[IBGInspector getCarrier] in InstabugHost_lto.o

ld: symbol(s) not found for architecture arm64

So in this post-Snowden world I have to wonder why does it need coretelephony, for example.

So what I'm getting at is that if you do not have the source the a 3rd party framework you have to disclose to the user that your app itself is NOT using microphone, or camera so that the user has an option of denying access to that device.

You don't want to be in the news someday due to some security flaw exploited via YOUR app.

Unresolved: The carefully crafted microphone usage description does not solve the issue with security completely though in case your app DOES use microphone and a 3rd party framework (think that it) needs it too.

Here's where credits disclosure could come handy giving users an idea which 3rd party code your are relying on. Give the credit where it's due :^)

If you are lazy such as myself and never read through the ios security whitepaper here's a short https://developer.apple.com/videos/play/wwdc2016/705/

In case you have no desire to watch the video in its entirety: around 19:00 mark the speaker tells you explicitly that you must not be lazy with those descriptions.