Help! My Audio Unit Version 3 (AUv3) is not working

I have had a lot of bother getting my head round AUv3s both with JUCE and just directly using Apple’s frameworks.

AUv3s appear to something not quite yet turn-key to build with JUCE and information of how they work and the problems you can run into (mostof the time self-inclficted) is thin on the ground.

I originally had this posted in OSX 10.15 debug AUv3 in Logic, but it now seems the wrong place for it. I am making this thread in the hope that other poor souls bashing their head against this for the first time might stumble across the right bit of information.

If you have self-sabotaged your own AUv3 project or resolved a pretty weird error share below.

NB: I’m not particularly interested in AUv3s, but the process of getting them to run on another machine has been so frustrating, I just want to get it to work out of spite.

Project Not Building

Problems relating to reasons an AUv3 project does not build

Embedded binary is not signed with the same certificate as the parent app

"Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target’s code sign settings match the parent app’s."

This error comes about for reasons I don’t fully understand, but that are fundamentally down to code signing.

To avoid this error

  • In Signings & Capabilities set both the .appex and .app to Sign to Run Locally
  • Do not set Development Team ID in your .jucer project under your Xcode Exporter settings

To actually sign the .app and .appex you will need to either

  • notarise via xcode† or
  • Via Terminal: codesign --force -s "Developer ID Application: Your Name (YOURID)" /path/to/ -v --timestamp

Given apps from Catalina onwards now need to be notarised, it seems silly not to take that approach.

Hardened Runtime is not enabled

As a sub-issue of sorts, if you Archive an app with no signing, then you will get an error during notarisation stating Hardened Runtime is not enabled even when it is. Make sure Signing & Capabilities at least has Sign to Run Loaclly checked.

AUv3 Not Registering

Problems relating to an AUv3 not registering.

Your AUv3 has registered properly if it appears when you run:

  • auval -a in Terminal
  • pluginkit -m in Terminal

Run the Standalone App first

Obvious to everyone except myself, but you need to run the standalone app before the AUv3 is registered by PluginKit or whatever it is that is registering appexes. You don’t need to sign if you are running on your own machine, just make sure it is Sign to Run Locally

Restart your machine

After running the app for the first time, I have had to restart my machine in order for the AUv3 to be registered. This is the case not just for High Sierra, but I found I have had to do it for Mojave as well.

No App Sandbox

A self-inflicted problem trying to guess the cause of another problem. The .appex need both the App Sandbox and Hardened Runtime Capabilities. If the .appex only has Hardened Runtime for notarising, the AUv3 will fail to register

AUv3 not Loading / Mounting

Your AUv3 is registered, but is either greyed out in your DAW or shows as red text in AudioPluginHost. Probably channel configuration related

Assertion failure in +[NSServiceViewController currentAppIsViewService], /BuildRoot/Library/Caches/

some variation on

Assertion failure in +[NSServiceViewController currentAppIsViewService], /BuildRoot/Library/Caches/ blah blah

my specific version

Assertion failure in +[NSServiceViewController currentAppIsViewService], /BuildRoot/Library/Caches/

Short version to fix this: Channel configurations.

Edit: Actually this might be a red herring, this error seems to come and go as it pleases with no real rhyme or reason.

Solution 1: Plugin Channel Configuration

This was sorted for me by stipulating a specific channel configuration in the .jucer project settings under Plugin Channel Configuration.

This introduced a separate problem in that the boiler plate JUCE project needed to be changed from

#ifndef JucePlugin_PreferredChannelConfigurations
: AudioProcessor (BusesProperties()
#if ! JucePlugin_IsMidiEffect
#if ! JucePlugin_IsSynth
                  .withInput  ("Input",  juce::AudioChannelSet::mono(), true)
                  .withOutput ("Output", juce::AudioChannelSet::stereo(), true)




Solution 2: follow the tutorials

Follow the Tutorial: Configuring the right bus layouts for your plugins to do Channel configuration correctly using isBusesLayoutSupported

Manufacturer and Subtype Codes

This one is probably the most frustrating as I can’t really wrapmy head around what is goin wrong. I have 2 identical projects

Project 1 manufac: Manu
Project 1 subtype: Qbcz

Project 2 manufac: Jhmh
Project 2 subtype: Mvcf

Project 2 refuses to work in any DAW

  • Passes auval
  • Works in AudioPluginHost

Both apps are exactly the same. I sign and resign, restart my machine multiple times, no improvement

I change the Project 2 codes to

Project 2 manufac: Zhmh
Project 2 subtype: Zvcf

and all of a sudden it works absolutely fine. If anyone has an answer for this one, I am all ears. The only lead I have is that consistently the first plug-in listed by auval always has the Assertion failure in +[NSServiceViewController currentAppIsViewService] error from above. That said, Project 1 is listed firsts, now shows this error, but continues to work absolutely fine.

† in the past, Xcode documentation has been atrocious, but the most recent version is actually not that bad all things considered. Keep The Xcode Docs handy


Thanks for your detailed description.
Much appreciated.

I can add my two cents to that:
If you plan to use both AU and AUv3 on your system, you might find that Logic does not like that. Once the AUv3 is registered by Logic, it refuses to load the AU. Even if you delete all references of the AUv3 from your Mac. That can be a bit frustrating, if you want to debug separate problems on AU and AUv3.

The only way I could make Logic re-recognize my AU was by building a new AU where I bumped the version number. Apparently only bumping the version number makes Logic / auval really do a rescan of the installed AUs and AUv3s.

Further update to Manufacturer and Subtype Codes:

~/Library/Caches/AudioUnitCache may have been throwing a spanner in the works. I’ve thrown-in a post-build shell script (See 7.2.2 Xcode Exporter Settings) of:

[ ! -e $AU_CACHE_FILE ] || rm -f $AU_CACHE_FILE;

which seems to be fine until someone lets me know how it could be a terrible idea.