Is there a complete (app+extension) AUv3 project?

The latest AUv3 demo from Apple (AUv3Filter) is based on Swift 5, which is not supported by my MAC/Xcode version.

Is there a macOS JUCE project (demo, tutorial, etc) that shows a complete AUv3 audio implementation?

By complete I mean something that shows both the containing app and app extension working together and they get built together in Xcode.

Fwiw, I’ve searched the JUCE site and didn’t see one. There are some old forum posts on AUv3 but they seem to be based on user projects and generally end in failure.

If not, is a new version of JUCE coming out that will have direct support for this?

1 Like

You can set up your plugin project to export to VST3, AU, AUv3, AAX, RTAS, Standalone, Unity, VST, Inter-app Audio with proJucer.

You just need to enable it here in the project settings:

You can load any of the Juce Plugin Demo projects, set them to export for AUv3 and be up and running right away.

Unless I missed your question entirely, this is a lot easier than you’re making it.

Hi matkatmusic,

Thanks for the reply and yes, generating an AUv3 plugin is that easy! However, it’s not complete. Another way to put this point is that the “.appex” output from this process is not stand alone distributable.

An AUv3 plugin (.appex) does not simply load into the standard AUv2 plugin directories. Instead, it’s packaged with an app, that Apple calls a containing app. The containing app, which includes the AUv3 .appex plugin as part of it’s package content, is the distributable.

In Apple’s AUv3 scheme, at the completion of containing app’s installation, the containing app automatically runs and calls the AUv3 packaged plugin. This process somehow notifies the OS about the plugin and then it becomes available to other apps (plugin hosts/DAWs) for use.

So I’m looking for an example JUCE project that shows the complete containing app and extension as one build.

Apples latest AUv3 demo does this but it’s built on Swift 5 and I’m currently fighting a lot of issues to ‘downgrade’ that to Swift 4 in my version of Xcode. Beyond that, I’d rather just build my app in obj-C, which is what I’d expect a complete JUCE demo project to use.

Does this clarify my question?

I think this should automatically work if your project contains both a Standalone and an AUv3 target. The Standalone should contain the .appex, and should install it on first run. Have you tried this setup? If so, which part of the process is failing? Is the appex not included in the Standalone, or is it failing to install?

Hi reuk,

I’m not sure if you mean by “your project” my JUCE or Xcode project. So here are the settings I use for both.

But to be clear, there’s really nothing failing, the JUCE AUv3 generated plugin builds successfully in Xcode, as an .appex.

My issue is the .appex output of is not stand alone distributable, i.e. loading it into the ‘standard plugin’ folders doesn’t work (by Apple intent).

Another way of explaining this is to say the .appex output (the AUv3 plugin), is located in the containing .app, which is in turn located in the standard Applications folder. The .appex can only be seen by selecting “Show Package Contents” on the AUv3 containing app. In this sense, an AUv3 plugin is loaded into the Applications folder.

Again, Apple’s latest AUv3 demo app does all of this but it’s based on Swift 5, which my setup has issues with. So, I’m hoping there’s a complete JUCE AUv3 equivalent project. I now doubt there is because it seems a new JUCE project type (AUv3 containing app) is needed.


In the Projucer, click the disclosure arrow in the “Plugin Formats” field and make sure that the “Standalone” format is selected, then resave and rebuild the Xcode project. You should find that the Standalone target is an .app which contains the .appex. Running the .app should install the .appex so that it can be used in plugin host applications.

Yep, that did it, JUCE is great!

One last question though, where is the source for the containing app?
The only source I see in Xcode is for the plugin processor/editor.

The plugin and app are built from the same source. The plugin is loaded in a ‘standalone wrapper’ which handles window creation and audio device management. It’s also possible to supply your own wrapper code by defining the preprocessor flag JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP and copying/modifying the contents of juce_StandaloneFilterApp.cpp somewhere in your own project.

Nice explanation but now one more question, where can I find juce_StandaloneFilterApp.cpp (really the full project)?

Believe it or not I’ve looked and can’t find it.

You can find it at modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterApp.cpp. On github you can use the “Go to file” button to locate any file by its name.

You can also look right in your IDE if you set the JUCE modules to be browsable:

So if I have this right, to create a 100% duplicate wrapper (as a starting point) with modifiable source, the needed steps are:

(1) Add duplicate “wrapper.cpp” and “wrapper.h” file to my Xcode project under Source here:


(2) Define the “JUCE_USE…” flag in the new wrapper.h.

(3) Build the project.

Is this correct?

I’m wondering if naming conflicts would occur between the newly added wrapper source files and the original source files still under the JUCE standalone plugin client module.

I’m also wondering if any other config changes would be needed in Xcode.

thanks for the tip matkat!


I’ve now tried adding copies of the juce_StandaloneFilterApp source files to my project and it created a lot of errors. Some are simple, like include files not being found due to path name issues, others are deeper.

Given that the automatic generation of the standalone app works, would there be anything wrong with just modifying the actual source files in the Juce standalone module itself? (As matkat pointed out, they’re accessible in Xcode).

I’d be OK doing it this way as long as I can be certain no ‘unknown dependencies’ are introduced between main (wherever that is in the standalone plugin) and it’s call to juce_StandaloneFilterApp.

Just looking for some guidance here because the structure of this app doesn’t resemble the structure of the other apps JUCE generates, they all include a clearly defined main and are easy to trace through.

I’d strongly advise against modifying the JUCE sources, as this will make it more difficult for you to update to new JUCE versions in the future.

To supply a custom standalone wrapper, try the following:

  • Copy everything from inside the namespace juce block in juce_StandaloneFilterApp.cpp into a new .cpp.
  • Add the following at the top of the new file:
    #include "juce_audio_devices/juce_audio_devices.h"
    #include "juce_audio_plugin_client/juce_audio_plugin_client.h"
    #include "juce_audio_utils/juce_audio_utils.h"
    #include "juce_audio_plugin_client/Standalone/juce_StandaloneFilterWindow.h"
    // Once the project is building, you should consider removing this line
    // and manually adding namespace prefixes where necessary.
    using namespace juce;
  • Add the following at the bottom of the file:
  • In the Projucer, add the new .cpp to your project.
  • Also in the Projucer, ensure that JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP=1 is present in the “Preprocessor Definitions” field for the project.

Making progress…after those changes, down to just a few errors in the Xcode build. All are related to:

#ifdef JucePlugin_PreferredChannelConfigurations

Here’s the first 2 examples:

How have you defined this macro?

Apparently, yes, by setting this in Projucer:


which is the correct config for my plugin, but obviously there’s more to the story here. Now I need to…?

You’re missing a comma between the } { there.

Yep, that did it!

Both macOS and iOS versions now build successfully. I tested macOS and it runs, I’ll check the iOS later.

I’ve got a lot to learn about Juce but I think I’m now in position to begin the real work of porting my AUv2 plugin to AUv3.

For others, here is the editable “main.cpp” I created by following all reuk’s instructions in this thread:

Main.cpp (4.7 KB)

and don’t forget this flag must be set in the Projucer project settings for it to build correctly: