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.
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 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.
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.
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.