Has anyone looked at whats required to properly include the AUv3 .appex bundles into an iOS application bundle, such that installation of the app also provides the plugins to other audio applications on iOS? (I’m assuming this will also work for MacOS).
I’m about to embark on this endeavour, and as I see it the following must happen:
Plugin is built and properly signed as an AUv3 .appex bundle.
Plugin bundle .appex is included in an iOS project as a resource of some kind.
That .appex is put somewhere appropriate in the bundle - must it be notarized again in the context of the .app bundle notarization?
Ultimately I’d like to have my plugins be sub-projects of the main “hosting application” somewhere along the line - has anyone looked into what this will take, from the CMake perspective, yet?
I’d love to get feedback/comments from anyone else interested in this issue - seems to me its a standard bundling technique on the horizon for us JUCE folks, anyway …
This is already handled for plugin builds with CMake. Note that AUv3 builds are only supported through the CMake Xcode generator.
Enabling the AUv3 and Standalone formats for a plugin will cause the AUv3 to be added as a dependency of the Standalone, and will also copy the AUv3 to the correct location in the Standalone bundle, so that installing the Standalone will make the AUv3 available to use in other applications.
Even if you need something more complex, the JUCE CMake scripts are still likely to be a good starting point, showing how to set up the dependencies, copying, and plists.
Understood, as I’ve done this to get the plugins installed and tested on iOS already…
But the issue is that we want to replace the Standalone code with a real “JUCE Application” - so would you suggest either a) adding the JUCEApplication code to an existing Standalone project, or b) modifying CMake to perform the .appex bundling on an existing (non-plugin based) Standalone application.
Of course I can evaluate this myself, but I think that this is something that might be of interest in future JUCE versions as well - i.e. the Standalone App is a mini-plugin host (as is the case with our app), and the Plugins are bundled in it … surely this would be the next logical addition to the app-bundling CMake functions? If so, I’d kind of like to breadcrumb-trail the process, or at least figure out if I can contribute to this functionality with a PR …
I think that option a will be easiest to get working. You can supply custom code for the standalone app by defining JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP, and making sure that you have a .cpp in your project that includes a JUCE_CREATE_APPLICATION_DEFINE (AppClass) line, where AppClass is your custom JUCEApplication.
The disadvantage of this approach is that each plugin will have its own enclosing app bundle. If you want to include multiple plugins in a single app bundle, then you’ll need to investigate option b.
Something else to keep in mind is that the AUv3 format allows a single .appex to include multiple entry points, so it’s possible to have a single binary which includes several different plugins. Taking advantage of this feature would reduce build time and binary size, assuming that there’s a substantial amount of shared code in each of the plugins. If we were to adopt a feature like this in JUCE, this is the direction I’d want to go, rather than building multiple .appex bundles.
