Installing new Audio Units requires restart in High Sierra

I’ve seen similar issues when building a JUCE plugin. A first (debug) build using High Sierra would not scan in auval (and hence not show up in Logic Pro X) until I log out or restart the mac. Funnily enough, despite the file being visible in Finder and in the terminal, auval claims that the plugin does not exist. After a reboot, auval does ‘see’ the plugin and validates it successfully, after which it shows up in Logic Pro as well.

Using the exact same project and process this happens on one machine but not on another one. Very confusing. The same project compiles perfectly fine on the same two macs when running Sierra. Note that High Sierra did upgrade the file system to AFSP.

I have found one work around for my case when building plugins. If I rename the AU plugin from its original name (let’s say juce_plugin.component) into something else (juce_plugin2.component), and then rename it back to its original file name (juce_plugin.component), auval scanning works fine and the plugin shows up in Logic Pro as well.

Don’t ask me why this works… :-/ The issue seems to be with auval claiming the file is not there until it is renamed, the user logs out, or the mac is rebooted.

1 Like

Are you saying that a simple mv Plugin.component tmp && mv tmp Plugin.component solves this?

“Solves” is a strong word. Ibuprofen doesn’t “solve” a headache. It just makes it so you can ignore it. :slight_smile:

1 Like

If it makes all the symptoms disappear and effectively causes the users to be perfectly satisfied, then even if it’s not the most elegant solution, it may effectively be a solution to the problem.

@djb is launching Logic between the two mv calls part of the solution?
If not it sounds like a placebo solution…

I can’t test, I am still on “low sierra” 10.12 (all threads about high sierra don’t make me wanting to upgrade, but doesn’t help, if my users are having the problems instead of me)

The workflow that worked for me on the mac with issues:

  1. Build the project
  2. Run auval in the terminal; plugin could not be validated (even if attempted multiple times)
  3. Rename plugin in Finder, and rename it back
  4. Run auval in the terminal again; validation works all of a sudden.

Just FYI:

  • The problem happens on one specific mac, not on another one.
  • The problem only occurs with High Sierra + AFSP, not with Sierra.
  • The problem is reproducible with many JUCE projects I have (not just one project specifically).

Whether the plugin shows up in Logic or not seems to depend on auval (if auval does not find or validate the plugin, it won’t show up in Logic).

If anyone can reproduce this workflow let us know. Also any light why audio units don’t validate without trickery in High Sierra, while it works fine in Sierra is much appreciated…


Some AUs won’t show, some will. I was able to reproduce this for JUCE/non-JUCE plug-ins and with APFS and without it…

To be honest, I really think Apple should resolve this. wonder if anyone within ROLI got in-touch with them.


Yes, this issue or similar ones have been occurring since AudioUnits were first announced. It’s not especially new, as such. It’s so omnipresent, we actually have years-old internal company shorthand for it. It started with someone saying “I have to turn around three times, spit, and wave a rubber chicken over the AU,” and has since been shortened to “chickened.” As in “the AU is chickened; hold on.” I just checked, and the first mention of “chickened” in our chat logs is in 2009.


I just got a “new” mpb 2015 and ran into this issue as well with High Sierra. While similar stuff has been happening since a long time, this seems to be much more widespread. The problem also happens in AU Lab, which I use for testing.

The workaround above tells us to use a finder rename, but I can confirm a dual “mv” in Terminal works as well. This means the workaround could be automated in an installer. However, it’s not clear yet whether this would even happen after an install. For me it happened when building a plugin for the first time on the new machine and having it placed in the user Library/Audio/Plug-Ins folder.

Then I tried using a .pkg installer that installs to the system wide Library. Unfortunately none of the workarounds worked on that and a restart was the only way to get hosts to see the AU.

1 Like

Thanks for letting us know!

Time for Apple to solve this mess :-/

Good luck with that…

1 Like

I doubt Apple will fix this any time soon. What would be nice was a reliable way to make what’s left of the Component Manager perform a rescan of the available components. This could maybe be done in a post-install script, but so far no luck. I guess that is what the renaming sometimes triggers. I already tried running “touch” on the installed files, but it does not help.

Does anybody know of any AUv2s which work without a restart on High Sierra?

I’ve just checked with QA and we’ve not been getting any reports of anything like this and we have a fair few plugins out there used by a lot of customers! We did see this behaviour way back when Yosemite was first released, we initially added a log out at the end of the installer but eventually we found a little trick that seemed to “fix” the issue. We ran this command in the installer auval -v "" "" "" > /dev/null 2>&1 || true this would seem to force some sort of cache to update (presumably because it would have to scan every plugin to try and find a match?) and the plugin would then scan correctly on the next load of the host. However I’m not convinced this is really fixing the issue anymore because looking at our installers it appears that at some point a regression has occurred and we’re not actually running this script anymore anyway!

1 Like

finally updated to high sierra, and low and behold I now have to restart to get newly installed aus to show up. Anthony_Nicholls trick didn’t work.

it happens with component manager and auplugin factory entry points

Could someone who’s experiencing this problem take a demo of one our plugins and let me know how you get on? If you don’t have a PACE iLok dongle, the VoxDoubler doesn’t require one (it uses a machine auth), but you will need a free iLok account (!registration)

Register here for a demo

YUP - had to reboot to get VoxDoubler to show.

please can anyone with contacts at apple try and get them to fix this? i have filled a bug report and emailed someone i know, if we all do that maybe something will happen?


Thanks so much @olilarkin for confirming that, I will get a message to our contacts at Apple tomorrow.

Can you share the bug number with us? I’ll send it to our contacts at Apple.