AUv3 hosting - iOS - three display problems!

Hi Folks,

I’m trying to host AUv3 plug-ins on iOS.

However, I’ve got a couple of major problems to note:

  1. if I select any of Apple’s (many) Audio Units (e.g. AUDelay, AUDistortion etc - which I presume come from GarageBand?), I just get a small, empty host window displayed.

In case it helps, this always results in the following assertion:

AudioProcessorEditor* AudioProcessor::createEditorIfNeeded()
    // You must make your hasEditor() method return a consistent result!
    jassert (hasEditor() == (ed != nullptr));
  1. If I select a 3rd party AUv3, such as Moog Model D or Wotja, I get the AUv3 displayed as expected… but there seems to be no way to resize it!!!

  2. Plug-ins which display properly, such as the Moog Model D, are displayed with the wrong size and wrong orientation!

Can somebody please advise on these three issues?

Thanks in advance :slight_smile:


Hi folks,

Is anybody out there using hosted plug-ins on iOS?

I’d assumed that if anybody was, they’d soon know if this was a problem for them or not :slight_smile:

Either way, I’d appreciate knowing if anybody else either sees any of these problem, or cannot reproduce them!

Best wishes to all,


I’ve had a chance to investigate these issues now:

I was able to reproduce this in the AudioPluginHost. Calling hasEditor() on these plugins returns false for me. I think the solution is simply to check hasEditor() before attempting to call createEditor(). I’ll add this change in the demo host.

For AUv3 plugins, the host should resize the editor to an appropriate size. The plugin cannot resize its own view. Calling setBounds() on the AudioProcessorEditor of an AUv3 plugin from the host should resize the view to the requested size.

The AudioPluginHost doesn’t make this especially clear, as the editor windows provided aren’t resizable. I plan to push a change which makes the editor windows resizable via the window borders - with this change applied, it’s possible to resize AUv3 editors in the APH.

I think this is the same issue as your second point. The host must request whatever size it requires. The plugin is not responsible for opening with the correct size.

1 Like

Hi @reuk, thanks so much for checking.

Really looking forward to trying out your fixes :slight_smile:

Best wishes,


Hi @reuk

Just playing with Garage Band, which shows a user interface for (say) AUReverb2 on iPad.

Do you think that Garage Band is constructing its own UI for AUReverb2 (etc.) …?

Best wishes,


I think if the plugin has no editor you can use GenericAudioProcessorEditor?

@eyalamir wow, I didn’t even realise that existed!

So surely, createEditorIfNeeded() would instead return an instance of that instead?

Best to all,


For now, I can bodge this like this:

    if (processor.hasEditor() == false) {
      return new juce::GenericAudioProcessorEditor(processor);

    if (auto* ui = processor.createEditorIfNeeded()) {
      return ui;


I’m not sure createEditorIfNeeded() needs to default to the juce generic editor implementation, as many times you want to pass forward the fact it’s nullptr or some other invalid representation of the editor.

Anyway I think what you’ve done is correct.

Thanks @eyalamir ! Pete

Just thought I’d mention that in my Plug-in host window, when the close button is pressed, I’m finding I’m having to do this on iOS otherwise something hangs around that prevents me tapping-though the to user interface. Can’t see why, but just in case it helps somebody…

    setBounds(-5000, -5000, 100, 100);
1 Like

I’ve merged the improvements to the AudioPluginHost now:

1 Like

@reuk thank you very much :slight_smile:


Sorry for hijacking this thread but are you able to get other plug-ins scanning and showing up?
(without first invoking GarageBand for example)

Maybe it’s the fact my iPad 7th gen uses A10 CPU?

Hi @ttg yes, no problem on that score!

So, for example, I see all the standard AUReverb2 etc. units (which I guess are installed with Garage Band).

Plus, I can see others I have installed, such as miRack.

Hoping that helps!


@ttg install the Free Wotja for iOS - which I wrote, and is Juce based! - and you should see the Wotja AUv3 as an instrument.

Hoping that helps!


Sadly also with Wotja it’s the same. unless another host was open earlier on my iPad 7th gen with 14.4, I can’t get any AUv3 to show up or scan properly. as in the issue above.

AUVerb2 isn’t a problem btw, try other freebie third part AUv3.

Nice app btw, it seems you’ve used a lot native UIViews?

Hi @ttg

Well, that is really weird then. I wish I knew what to suggest!!!

Unless, perhaps, your host app is missing permissions / not signed properly (just clutching at straws here).

Many thanks for your kind comment. Actually, no! :slight_smile:

Rather, Wotja’s UI sits on top of a “UIKit-like” layer I wrote (with a navigation model etc.) that in turn sits on top of Juce. It took a lot of work, but it means that Wotja feels pretty close to a native iOS (or macOS etc.) app, despite actually using Juce for all of its rendering!

IMO that is a big missing layer in Juce. I mean, there is nothing technically to stop any dev from creating their own layer, like I did, but it certainly took a lot of effort to create it, and then polish it!

Best wishes


Just to say that one thing that really bugs me about a lot of apps, is that so many of them seem to bring their own design language. We’ve worked pretty hard to keep ours very mainstream, i.e. as close to standard iOS vanilla app as possible. Wotja is hard enough to learn, without having to learn a different UI language :slight_smile:

My app is behaving the same when signed and not. Does your app has IAA entitlement? Or can be loaded as IAA plug-in?

So also the action sheets aren’t native iOS?

And your dialog boxes with text input?