iOS AUv3 size negotiation

Ok, I’ll try your way to go. Nevertheless, I have the feeling, that there are two different approaches. Yours seems to replace the AudioProcessorEditor::standardConstrainer with your own one.
My way is to adjust the standardConstrainer with setResizeLimit () and setResizable (). In my opinion both approaches should work.

@t0m Could you maybe comment this?

You’re correct: if you haven’t created an explicit constrainer and assigned it to the resizer, then this will not work. I don’t know why that is. The entire size negotiation is a bit of a hack, as it devolves from an AUv3 method for asking whether the plugin wants a keyboard, supportsHostMIDIControllerPresence, which is lame for an effect. But it’s worth noting that AUv3 is very much a moving target, so this sort of nonsense is to be expected.

EDIT: I think I see why it doesn’t work. If you just adjust the standard constrainer, the resizer doesn’t have a pointer to it. The negotiation looks for a resizer, and then asks that resizer for the constrainer it points to. If one hasn’t been assigned, the fallthrough works in the standard method, but not the size negotiation. You should make one anyhow, because you have more control over the sizing and suchlike.

Unfortunately no success, yet (I now followed exactly your approach). I’ll go on tomorrow.

I’m having the same issue with Garageband. Cubasis and Audiobus show a full size option but nothing I do, including the above tips, makes the full size option appear in GB. I’ve tried numerous constrainer bounds and aspect ratios.

I tried setting a breakpoint in getSupportedViewConfigurations to see what Garageband is looking for in terms of size, but it never triggers, so it appears that method isn’t being called. Is there something I have to set in order to have getSupportedViewConfigurations called?

Okay. I think there might be some confusion. Cubase and AudioBus don’t do a negotiation. They just full-screen. They’ll fullscreen anything. Ditto AUM and BeatMaker 3. (Go ahead and try it. Hardly any commercial AUv3s have size negotiation, yet all of them will fullscreen in those hosts.) The negotiation is really only for GarageBand at this point, and as far as I’m aware, only for instruments. I do not believe that effects can be fullscreened in GarageBand, but I’m willing to accept empirical evidence to the contrary.

One could test this by making a quicky instrument with the code I provided above. Also note that the minimum build target for this entire process is iOS11.

I get around this entire nonsense by building the UI how I want it (in our case, identical to our desktop versions, for the most part) then adding a button to slide the entire thing up. This lets one use the full UI in hosts that support it, or the natural AUv3 size in hosts that don’t, or for convenience’s sake. e.g…


Versus the same plug in AUM…


@crandall1 It was the deployment target setting iOS 11!!!
It was on 10. Thank you for highlighting this!

Your plugin looks great. Cool idea with the up/down shifting.

iOS 11 deployment fixed it for me as well. Thanks for all of the info.

I’m just sorry I didn’t mention that at the top; would have saved you both a lot of head-scratching. :slight_smile:

But yes, AUv3 size negotiation didn’t appear until iOS 11. (Virtually all the good features of AUv3 are iOS 11 or greater. Prior to that, it’s just stupid rectangular turtles all the way down.)


Hi, anyone managed to get constrain limits working on AUM? I’ve tried examples shown by @crandall1 above, but don’t seem to have any effect.


Sorry, just saw this.

As I mentioned above, constrain limits do not work in iOS AUv3. The plugin has no control over the sizing, other than telling the size negotiation what your range of available sizes is (and this is only to allow fullscreen in GarageBand. It serves no other purpose.)

Once again:

  1. Set your resizer min, max, and aspect ratio in Editor’s constructor, and attach the constrainer to the Editor.
  2. At the top of resize(), ask for the width and height you’ve been handed. (I suggest using an arbitrary scaling, and draw everything off that. e.g. myX = getWidth() * 0.01)
  3. Draw everything.
  4. Profit.

You can not tell an iOS AUv3 anything about the size otherwise. You are strictly reactive, and have to take in to account what you’ve been handed. Look at our (Audio Damage) or Bram Bos’ more recent products like Ruismaker Noir to see how to deal with this in various ways.


Thank you for your input on this. I was wondering how to get that fullscreen button working for a couple hours! I see what you mean that the DAW or host doesn’t give a crap about the plugin’s actual size. It only cares what sizes the plugin lists that it supports. I am following the AUv3FilterDemo example from Apple not using JUCE (I still love JUCE!). Theres a class in the Core Audio Kit framework from Apple called AUAudioUnitViewConfiguration which I believe has a method called supportedViewConfigurations. That method is called by the host at some point according to Apple, and the host will pass in its available configurations. Then the plugin can override that method to logically check if it supports the configurations the host passes through. If it does, it will return those configurations to the method. I realized this example I was following wasn’t returning any configurations at all. Garageband iOS on my iPhone 7 (iOS 14 beta to be specific) reports that it supports (667.0, 202.0) and (667.0, 315.0) which the latter would be what causes the fullscreen button to show.

I hope this helps someone, and I’m glad I wasn’t the only person experiencing this confusion!

If you search supportedViewConfigurations in the JUCE AUv3 wrapper code, you will see that it is there already. You don’t need to do anything, other than following my instructions above, and ensuring that your resizeLimits’ maximum width, height, and ratio can contain the full screen of a 12.9" iPad’s maximum AU view in GarageBand. That’s all.

EDIT: I just see you’re not using JUCE, so this is just for the benefit of people finding this in a Google search. I get it.


That sounds a lot more painless. Yeah it was hard to find documentation on how to use supportedViewConfigurations, so it’s probably a good thing you don’t have to deal with it directly in JUCE. I’ll have to play around with it there too. I’m just getting started with JUCE and I love it so far. Having all those checkboxes for all the different plugin formats is great.

Just noticed that this does not work anymore in my case with the latest JUCE 7.

The following code in is never true in my AUv3 iOS plug-in in garage band and because of this it does not add the full screen view to the supported views:

if (modifiedBounds == requestedBounds)
  [supportedViewIndices addIndex: i];

This used to work in the past. I also set iOS 11 in the deployment target. Can someone verify this?

I was able to solve the problem. My solution was to no set any aspect ratio and let the plug-in handle how it uses the available space.