AUv2 and AUv3 compatibility

To clarify

  • macOS AUv2 → iOS AUv3 → Impossible to test until logic pro is released tomorrow for iPad as GarageBand is only one way (iOS doesn’t have the full features)
  • macOS AUv3 → iOS AUv3 → Impossible to test yet (as above)
  • iOS AUv3 → macOS AUv2 → Instantiated; Doesn’t restore state
  • iOS AUv3 → macOS AUv3 → Instantiated; Restore State


1 Like

See above… But in addition, I would imagine that it will be the case going the other way however… It will swap a plugin in if it recognises the code but won’t try to get it to restore state.

OK. Thank you so much for testing and clarifying this.

Thought I would also list my findings about converting plugins for use as AUv3 on macOS as and when I find them. The first is to put this in LookAndFeel. The “#if JUCE_IOS” was previously required for iOS stuff to get popup menus to work. Seems the case on macOS swell.

    juce::Component* getParentComponentForMenuOptions (const juce::PopupMenu::Options& options) override
        if (options.getParentComponent() == nullptr && options.getTargetComponent() != nullptr)
            return options.getTargetComponent()->getTopLevelComponent();
        if (juce::PluginHostType::getPluginLoadedAs() == juce::AudioProcessor::wrapperType_AudioUnitv3)
            if (options.getParentComponent() == nullptr && options.getTargetComponent() != nullptr)
                return options.getTargetComponent()->getTopLevelComponent();
        return LookAndFeel_V2::getParentComponentForMenuOptions (options);

Thanks @DavidCNAntonia for starting the discussion on AUv2 vs AUv3 compatibility.

** iOS AUv3 → macOS AUv2 → Instantiated; Doesn’t restore state*

Does anyone know if this is a JUCE issue or a Logic issue?

Related observation: it seems AUv3 in Logic always runs inside a sandbox even if the corresponding main app doesn’t have a sandbox enabled, which causes issues with VST, VST3 and AU plugin versions that do not run in sandboxes as it becomes difficult to share preset and user patches among them… Has anyone observed this as well?

I also wonder if we just can update our macOS plugins from AUv2 to AUv3 without having them sandboxed or other downsides for macOS users.

I don’t think you can avoid running in a sandbox but there are some “temporary exception” entitlements that you can use to get access to the macOS file system as before. How long those will remain available to use is anyone’s guess. It’s the kind of thing that sounds risky to lean on and deprecated from day one having temporary in the title!

These can be configured in the Projucer.

There are some things that we don’t have exceptions for, such as some types of network access which prevents some copy protection schemes from working.


Thanks for the info. I also think this sounds a bit risky and it takes away some flexibility and usability that desktop users expect.

@mfritze Any chance that Logic also loads the state of an AUv3 into an AUv2 plugin for iOS / macOS compatibility? Some plugin developers can’t or don’t want to support AUv3 in macOS because of restrictions and usability.

The sandbox is a strict requirement for all new applications. If you need access to more files, you need to declare it and ask the user for permission.

There is some wiggle room right now to not completely break backwards compatibility, but you can expect that this will be cleaned up in the future, because these issues are security nightmares.

Thanks for the clarification. This sounds like you have to make Logic X on macOS also sandboxed in the near future. Is there any schedule for this? Other DAW’s too?

Interesting, does this mean that the sandbox requirement will also be extended to applications outside the App-Store?

I can not make these statements. It helps as well, that I do not know the future…

But I look into the past and security increased over the years and seems to continue to be moved forward. That means: any “trick” that might work today, might break in the future. If a security researcher stumbles across something bad, it might even change very quickly.

So, in general: it does not help to work against or around best practices recommended by Apple. That might work for a bit, but can burn you at the most inopportune moment. We found a lot of these issues during the Apple Silicon transitions.

Also: with Pro-Apps now being available on the iPad, I can only assume that a lot of developers want to bring their AUs on iPads as well, because it is a new market to sell to. And to be compatible with iPadOS you need to be sandboxed, etc. anyway.


Can you maybe elaborate on how all this sandboxing would work on a practical level for instruments that have large libraries?

Our flagship product “NEXUS” currently has a library of around 227 GB of samples and presets. Around 30,000 of those are presets, the rest are samples that get loaded by the presets.

Ideally, we would need something where we can ask the user once for permission to access a certain “root” folder (the location of the content folder itself), and then we would have full read/write access inside that folder forever. We can’t ask the user every time a plugin is loaded or every time a preset is loaded. It has to be a one-and-done operation.

We have our own built-in browser with advanced searches, bookmarks, etc., and the user expects a single click on any preset to instantly load it. Asking the user every time is simply not a viable option.

Installing our content to a fixed “safe” location is not a viable option. Due to its size, most users want to install it onto an external drive.

We haven’t looked into sandboxing too deeply, but it’s becoming a concern.

Without adding my opinion about “the Apple” way, the scoped access should work (as long permissions won’t be removed).

Basically at least on iOS which hints about macOS “walled” approaches.

  • You ask for the native file browser.
  • User selects the folder they desire the allow the app to access onward.
  • The app should keep the security descriptor.

So now, any access should be done with the security scoped resource.

1 Like

See also:

Bumping this - we’re getting more and more customer requests to ensure that plugins running on macOS and iOS can restore plugin states and settings across platform (Garageband, Logic).

Before jumping into an investigation ourselves I was wondering if anyone else, or the JUCE team has started to look into this?


Still getting reports from users that they can’t load the iOS AUv3 presets in Logic X with the AUv2. What is the best solutions to resolve this?

I think about following steps to solve the problem:

  • Patching JUCE and ignore the loading error
  • Upgrade the AUv2 to AUv3 (not sure what that does mean for existing AUv2 users)
1 Like

I’d be keen to hear suggestions as well. Releasing AUv3 for macOS has some non-trivial implications that we’ve observed:

  • Sandboxing: it seems AUv3 on macOS runs in a sandbox which could mean that files (presets etc) saved by AUv2, VST, VST3 are not accessible (?)
  • Resizing: from what I’ve seen, an AUv3 plug-in size is determined by the host and not by the plug-in like AUv2, causing resizers etc to stop working
  • Logic seems to always open AUv3 if both AUv2 and AUv3 of the same plugin are installed, which could be challenging for users who don’t like the limitations that come with AUv3…

A way to allow JUCE plugins to work seamlessly between AUv2 on macOS and AUv3 in iOS would certainly be the easiest solution…

There are ways to disable file sandboxing in AUv3, so this shouldn’t be a problem as long this workarounds still work. Only network access is limited if i remember right. It will be impossible to add a subscription license in the future or verify the license because of this. This is the reason why i would like to stay with the AUv2 to keep this option open.

This is true.