JUCE and macOS 11 / ARM

I would not be too sure about that.

I just played around with that Reaper build on my DTK running Mac OS 11.0.1. Reaper is able to load AU and VST plugins compiled for x86_64 only, with AU being silently bridged by some layer obviously supplied by Apple (Logic uses the same) and VST being a bit more obviously bridged by Reapers own implementation that was already available to bridge e.g. 32 Bit x86 plugins running in a 64 Bit x86_64 environment. You can see that AU bridge in the activity monitor, look for AUHostingCompatibilityService (Reaper) there.

I also managed to run a universal binary VST3 natively in Reaper, but I’m not sure if in case Reaper detects that the ARM part of a UB cannot be launched, the bridge is being used silently in the background?


Weird, when I tested with the Reaper ARM build, it loaded my universal plugins as ARM versions for all three plugin formats.

It doesn’t appear that AUHostingCompatibilityService is running - the only difference to my setup is that I am running Big Sur Beta 5 (I’m downloading the release version as I type). The only thing reaper in activity monitor is saying that it is running as “Apple” rather than “Intel” in the “Kind” column.

1 Like

Out of curiosity, what happens on 10.9 for plug-ins? they aren’t even scanned? or they are scanned but crash on loading?
Also, does this apply to the Stand-alone version too, or that one does also run on 10.9?

They fail scanning. I believe loading the dylib is failing.

Standalone should be fine.

Finally got this working. I had to enable “Runtime Exceptions: Disable Library Validation” for the plugin to pass AU validation with the release build. Not 100% sure why but it now works. Give it a go if your ARM builds are not validating in logic.


Was running into this issue myself and this was helpful! After some digging around on the Apple forums I also discovered that library validation is only available for macOS 10.9 and up. I was able to get my AUs to run in ARM mode by including the Runtime Exception you suggested, but changing the OS target to 10.9 or higher also fixed the problem without needing that exception.

Im wondering now why this is only an issue with the ARM builds, if library validation doesn’t work when you target 10.8 why isn’t that an issue for Intel builds? Seems like we might keep discovering some back compatibility quirks with these Universal Binaries for a while.


It’s interesting you find it works with 10.9 and higher as I target 10.11 so by that theory it doesn’t quite match up, there must be something else going on.

1 Like

I’m in the same situation as you have been (plug-in failing when rescanning in Logic because of complaint regarding “arm64e” architecture, and manually launching “auval -comp” says that it couldn’t find the component)

Have you been able to find the problematic settings that cause that?

(might have to spawn a new topic about that shortly if I cannot find a solution soon)

I think removing QTKit framework from Xcode project will do the trick. Don’t forget to clean project before building (for a start, i suggest you to manually delete existing/non-working component file as well).

Thank you, but the fact is that QTKit has never been in the project so that can’t be the cause.

I’m seeing the same problems with a plug-in compiled from a default plug-in project just created with Projucer. Time to create a specific topic on the subject

Done so, the new topic for that specific issue is: Default AU from Projucer fails auval on Apple Silicon Big Sur (DTK) [SOLVED]

I’d be interested if @zabukowski (or whoever is happily validating AUs on their ARM64 macs) could comment there with the version number of auval that they have (and possibly of macOS, I guess that might be a factor too)

EDIT: I’ve solved the issue, visit the linked topic for the detailed description of what the problem was

How are you able to target 10.8? The min Xcode version for ARM is 12 and the lowest possible target sdk appears to be 10.9 or am I missing something?

My mistake, I set the target in Projucer to 10.8 but this didn’t carry over to XCode and it instead was 10.9

Just picked up a new arm machine and with Xcode 12.2 I’m finding Time Profiler will not show symbols for DemoRunner (and my own app). If I go to Instruments -> File -> Symbols -> Expand “DemoRunner” is says “Permission to profile this process was denied. Applications you wish to profile must be signed with a developer code”. Changing signing options however doesn’t seem to have any effect. For testing sake I created a blank swift project in Xcode and that had no issues with symbols despite having no code signing options set. Wondering if anyone’s seen this. Searching google for that error message brings up zero results.

1 Like

I found this and had to put set my signing ID in the xcode exporter settings in projucer. Works fine now for testing.

1 Like

Thanks, that indeed seems to fix it! I’m using cmake so I used the instructions in the CMake api doc to add the code sign identity and development team. I couldn’t figure out how to apply them to the DemoRunner but I followed the instructions for building the basic GUI app and that worked.

I must say it’s still strange that changing these settings in Xcode isn’t enough. And it’s also strange that creating a project in Xcode (and downloading one from apple’s dev site) happily profile without the need for this. My guess would be that there’s something configured wrong in the JUCE generated projects. Or maybe Apple is giving preferential abilities for it’s own project files or something? That’s probably far-fetched but who knows.

I double checked on my other machine using the same test setup (Cmake GuiApp example) and confirmed that the signing information is not required for profiling with that setup.

Machine 1 (no signing required) : intel, Catelina 10.15.6, Xcode 12.1
Machine 2 (signing required): m1, Big Sur 11.0.1, Xcode 12.2

Both machines used current JUCE master with CMake 3.19.1

I’ve now discovered that changing anything in the project file from within Xcode will cause Instruments to stop showing the symbols again. Between this and swift projects not requiring signing I think I’ll chalk this all up to bugs in Xcode.

@ graeme-2 how did you get cmake to with juce ?

Im having issues with juceadie compiling, it appears to be assuming mac are intel?

Ive got cmake (from homebrew) building my other cmake native projects successfully… but juce is throwing errors.

FIXED: needed to pull new version of juce - thanks @reuk for the info