Would it be possible to make a minor adjustment to the Xcode project builder for iOS in ProJucer so, in the event we are building an audio plugin with standalone (which it requires, obviously), this line or something similar is added to the Info.plist of the standalone?
With iOS 11’s advent, they now require an Info.plist entry with this line; the text isn’t that important, but it has to be there to pass review. I forget to re-add it nearly every time I rev the version, and it’s a moderate pain.
I worded the OP poorly. What I meant was, in the event of Microphone Access (which should be selected by default in an Audio Plugin rendered for iOS) could there be a sensible sentence of text included, rather than the Xcode default.
The reason for this: the Xcode default text will cause a rejection, 100% of the time, and the way that they reject it, a lot of newcomers to App Store submission won’t actually be able to figure out why. When you do a ProJucer hit on the project, the info.plist is rewritten and you need to remember to change the text every time.
What do you mean by 100% rejection? We don’t use the Xcode default text - we use our own (rather generic) string, “This app requires microphone input.”.
Since the advent of iOS 11, I get rejected 100% of the time with the default text, when submitting a standalone/AUv3 combination. I don’t know what the bounds are for rejection, but I swap it to an explicit statement of the app’s intent (something on the order of “this is an audio effect, and requires audio input. If you do not have a USB audio interface connected, it will use the microphone”) and that passes without drama.
EDIT: It’s worth noting that updates to existing apps and TestFlight submissions of new apps seem to pass (since they’re generally done with the automated testing.) It’s specifically new submissions for App Store review.
Is Microphone access a must for a standalone?
It might be nicer if I could explicitly not have microphone (eg. I’m making a tone generator / synth) since now you must enable this permission even though it’s not being used…
Sorry, it was my bad. since Ableton Live VST3 must have inputs, I had inputs set (even though I don’t use them).
So when I’ve targeted iOS I wasn’t aware of the inputs.
Once they’re removed, indeed, the JUCE Standalone Wrapper won’t try to have Microphone access.
If your auv3 standalone wrapper actually instantiates your plugin/synth then you might need microphone access, depending on how you need to fire the juce standalone wrapper audio engine. Don’t know if you might run into problems by firing an audio engine with 0 inputs (no microphone access) and 2 outputs.
If on the other hand your standalone wrapper us just a dummy landing page app for your Auv3 then in principle you don’t need any permission
fefanto is correct. If you use the “stock” JUCE standalone, and your BusesProperties() has any .withInput() at all, this will trigger the microphone modal. (Or, if you’re using the old school {n,n} like some sort of crazy person, if the first number is anything but zero.) If you’re using an empty carrier app, it doesn’t need a plist entry for the microphone service, and you can’t add one to the AUv3 plist anyhow, so problem solved. You have a new problem though, as empty carriers are very difficult to get through Review.
