Great work - thanks for taking the time to inform those of us who are also working on AUV3 builds. I’ll be very interested in any other gotcha’s you run into - I am preparing something similar for our (Austrian Audio) free plugins, too …
For an AUv3 plugin, it looks like the BUNDLE_ID set in the CMake file is only used to set the CFBundleIdentifier key in the appex bundle’s plist. Given that keys in the PLIST_TO_MERGE take precedence over keys specified in other ways, I believe that it’s possible to set a different ID by adding something like this to the juce_add_plugin call:
Note that this will set the same ID on the AUv3 and its standalone, so the generated AUv3 will need to be copied into a different Standalone with a compatible ID in order for the appex to be discovered and loaded.
Are you trying to do this with a single juce_add_plugin call?
I’d imagined that you’d call juce_add_plugin once for each AUv3, and optionally once more for the Standalone, and then copy the AUv3s all into the same Standalone as a post-build step.
Is the problem that you are building each of the inner plugins in other formats too, and that you need the bundle ID for the AUv3 version to differ from the bundleID for the VST3 version (for example)?
No, I’m totally fine with multiple calls! (see below)
Yes, but Apple has a strict requirement for the Bundle ID. It has to start with the one from the standalone, and then only differ in the extension with no additional dots, as seen in the Mela IDs, otherwise this will fail.
Our AUv3 deployment is not related to the VST3, AAX ones, etc.
So after forking JUCE CMake + JUCEAide, I’m able to do:
#Instrument plugin: has the standalone:
FORMATS Standalone AUv3
PRODUCT_NAME "Beat Scholar-MAS")
#MIDI FX plugin: no standalone, has a custom extension:
PRODUCT_NAME "Beat Scholar MIDI-MAS")
#add the midi component as a dependency of the main plugin
#(copy_full_dir is similar to juce_copy_dir but also follows symlinks).
After doing the above, I see a single standalone with two .appex files, one is:
And the other is:
Both can be archived just fine and pass the app store validation.
It would be great to have more cmake template in the examples/cmake folder. It would help a lot of people to start with it and show trickier use case like app with resource and other stuff like this Auv3 stuff.
@reuk , while I think it works for now, looks like xcode also throws a warning during archiving:
User-supplied CFBundleIdentifier value 'com.Modalics.BeatScholar-MAS.MIDIFX'
in the Info.plist must be the same
as the PRODUCT_BUNDLE_IDENTIFIER build setting value
Edit: Never mind, fixed with an explicit bundle ID set: