Hi @ttg
Yes, the app does have IAA entitlement (that is for our AudioBus support).
The extension doesn’t of course. 
I’d be surprised if that were behind your problem though, TBH.
So what I’m doing is, using the services of juce::PluginDirectoryScanner
I’m actually doing each step of the scan as a separate operation in a background NSOperation queue instance, in case that is important.
The “formatToScan” that I’m passing-in is just default:
juce::AudioUnitPluginFormat formatToScan
Maybe… have you configured your Juce project to support AUv3 properly?
#define JUCE_MODULE_AVAILABLE_juce_audio_plugin_client 1
#define JUCE_MODULE_AVAILABLE_juce_audio_utils 1
#define JUCE_PLUGINHOST_AU 1
I think they’re the key ones.
Aha, yes, our action sheets are native iOS, good spot. So on iPhone/iPod, we use native action sheet menus, and on iPad we use native pop-up menus (which, frankly, are much more attractive than the Juce built-in ones - that required a bit of a Juce patch).
Message boxes (alerts) are also native - and yes indeed, text entry. The text entry VC is handled via a layout in a storyboard, and a bit of Swift - nothing fancy.
I had to work quite hard to get iOS (and Android) keyboard pop-ups to work well with Juce, in the context of screens that are otherwise “pure Juce”. If you were to look at one of the script editors in Wotja, you should be able to see how this works in practice. Required some modest patching to Juce. I’m quite pleased with the results of the work I put in, however!
Best,
Pete