Calling in Juce… we get internal strings as follows:
“An OS error occurred during initialisation of the plug-in (-3000)”
“An OS error occurred during initialisation of the plug-in (-1)”
NB: -3000 is for a couple of the plug-ins, -1 for most of the others.
the audio plug-in host demo works fine (scans all AUv3 and the SoundMagic plug-ins)
my app fails to load the sound magic plugins (scan fails, as outlined above - but finds the AUv3 plug-ins); NB all my code does is create an instance of juce::PluginDirectoryScanner, and works directly through this… so this is really weird.
if I replace my custom scanner code with an instance of juce::PluginListComponent, on which I call the scanFor method… the plug-ins also fail to scan; but, additionally, this doesn’t pick-up on AUv3 plugins!
I’ve verified that the SoundMagic plug-ins are all signed; and that re-signing with my own cert makes zero difference
makes no difference if I sign the Audio Plug-in Host demo app
If I enable App Sandbox for the Audio Plug-in host, then it all continues to work.
EXCEPT: it now fails to load the plug-in that I re-signed.
Failed to create, errorMessage=An OS error occurred during initialisation of the plug-in (-3000)
So: it looks like the failures I’ve been seeing, are probably failing due to a combination of the way the plug-ins are signed, and my app being a sandboxed app. In that, the differences in behaviour are due to the sandbox settings interacting with plug-in code signing.
To be clear: we’re a hardened runtime, running in a sandbox, just like all app store apps (Logic is an EXCEPTION where they seem to make their own rules ) … and the macOS Security System prevents our app from loading such plug-ins.
Yes folks, even one of Apple’s own plug-ins falls foul of this!
Anybody reading this on macOS: please try the above little script.
If you see any plug-ins where you see the above reported, I’d suggest you ask the vendor if they might update their plug-ins to work with App Store apps!
Suggested boiler-plate when contacting - as I’ve already been asked this!
Dear xxx. Please refer to (link) which has allowed me to find that some of your plug-ins cannot load in App Store apps. due to not being marked as “sandboxSafe”. (list what you find here) Can you please verify this, and let me know when you might push-out an update? Best wishes, (your name)
In Apple Docs - Audio Components and the App Sandbox it states:
“If an Audio Component does not meet the requirements to be Sandbox Safe, it must declare to the system the system resources that it requires access to.”
and
"The system will compare the resource usage information provided by the Audio Component with what the host process’s sandbox allows.
If the Audio Component’s resource usage is completely allowed by the sandbox, the Audio Component is considered Sandbox Safe for that process.
Such an Audio Component will automatically have the flag, kAudioComponentFlag_SandboxSafe set on it and it will always be allowed to be loaded into that host process."
Yes, this is what I mean. Apple’s documentation suggests that the plugins will be marked as sandbox safe automatically, if the host (your app) sandbox allows the resources required by the plugins.
Since all JUCE plugins, by default, require network.client and temporary-exception.files.all.read-write, ensuring that your sandbox provides those will ensure that all JUCE plugins can be opened by default, without requiring the plugins to change
Sure. The thing to bear in mind is our app is from the App Store, so has to run with very strict sandbox / hardened runtime restrictions - we don’t have much scope for carve-outs