I’m using the OpenEars framework in one of my apps. It’s been recently rejected. The reason:

“During review we were prompted to provide consent to use the microphone, however, we were not able to find any features or functionality that use the microphone for audio recording.
The microphone consent request is generated by the use of either AVAudioSessionCategoryRecord or AVAudioSessionCategoryPlayAndRecord audio categories.
If you do not intend to record audio with your application, it would be appropriate to choose the AVAudioSession session category that fits your application’s needs or modify your app to include audio-recording features.”

Is there any way to fix it? The only part of the app where I’m using the microphone is where the OpenEars framework is being used.

Thank you

I’m sorry you had an app rejection — this is the first time I’ve ever heard of one as a result of using the framework for a purpose it was designed for (I heard of one other temporary rejection back in 2011, but it was due to an obvious misuse of the framework). Are you doing speech recognition in your app or just TTS?

I’m doing speech recognition. Only recognise 2 words (“next”/”forward”) to navigate between slides in one section inside the app.

I’ll give you some more background about the app:
This app is part of a family that has been using the OpenEars framework since iOS 5. When I release a new app I change the content, themes, and I update the UI and code to work with the new iOS version requirements.
The only place where I use the microphone is in OpenEars framework and Apple never reported a problem about it. This is the first time I release an app from this family for iOS 7, so I don’t know if it has something to do with iOS 7?

According to Apple I’m using audio recording, but the only thing I do is recognising 2 words with OpenEars

Starting with iOS7, whenever the mic is first made live in the app, the user is asked permission for mic access. This is a very good thing in my opinion, especially for applications like speech recognition. Apple’s rejection is basically saying that you are getting this permission, but it isn’t clear to them what you are doing with it and they want any mic-using feature to be made apparent to new users of the app. I don’t know what your UI is like so I don’t know if this is an accurate critique or not; not every reviewer is the same and they have a lot to do and can occasionally overlook things like everyone else, but let’s operate on the assumption that it’s correct.

Solving this in a definitive way is an app implementation issue rather than a framework issue and is probably something more for the realm of visual UI than speech UI, which isn’t inside of the scope of things OpenEars tries to do (besides giving you hooks like the audio input volume so you can create a visual UI in your app). But since it is clearly a concern for Apple, which means it’s a concern of people using OpenEars, I will add a warning about the necessity of communicating the fact that the app is using the mic for speech recognition in the OpenEars documentation.

I can make some suggestions about how to indicate to the user that there is ongoing speech recognition. You could describe it via an introductory alert on first run, right before starting the speech recognition so that the permission request appears in the context of allowing speech recognition. Alternately you could probably indicate it with a label or an icon.

Since you have the rejection email, though, I would simply ask them directly. “My app is performing speech recognition by doing keyword spotting as part of its user interface, which is why the PlayAndRecord audio session is in use. Based on the rejection reason, this voice UI feature isn’t apparent. What would be the best way for me to indicate that my app has a voice UI to my users so that the features or functionality that use the microphone for audio recording are clearly apparent?”

Sorry, that’s frustrating. You can set this behavior by setting the property noAudioSessionOverrides to TRUE in your FliteController. Please test that it gives the desired result of no audio session overrides on a new install of your app before re-submitting!