Issue with Audio Unit on 10.11

Hmm, if there hasn’t been a second update fixing the first one, I think it’s very likely that already affected machines will stay affected. If I find time to test this I’ll let you know.

The test machine we set up to reproduce this didn’t have any connected iOS devices, but the relevant itunes update was on there.

1 Like

Can confirm this works on a 10.12.6 install

It was a clean install, followed by installing all available updates, including “Device Support Update”, “iTunes 12.8.2” and “iTunes Device Support Update”

Following those updates, running Auval would say:
FATAL ERROR: OpenAComponent: result: -1,0xFFFFFFFF

After removing the link to CoreAudioKit and resigning the plugin, it works again, without changing any MobileDevice.framework etc.


I just tried it and now my plugin won’t load on 12.2.1. I didn’t bother to test on 10.11

validating Audio Unit Nexus by reFX:

    AU Validation Tool
    Version: 1.10.0 
    Copyright 2003-2019, Apple Inc. All Rights Reserved.
    Specify -h (-help) for command options

Manufacturer String: reFX
AudioUnit Name: Nexus
Component Version: 4.0.9 (0x40009)

* * PASS
FATAL ERROR: OpenAComponent: result: -1,0xFFFFFFFF

validation result: couldn’t be opened

Any update on this? We got several customers with the same issue on 10.11.

Has anyone found a solution with CMake that is similar to the ProJucer patch I posted above? I’m relatively new to the Juce CMake solution and excluding CoreAudioKit.framework at the end of the process is harder than I thought and it might needs a patch somewhere. Or maybe I’m just not understanding the process well enough - I don’t see where the frameworks list is stored when CMakeLists.txt is executed.

“We’re going to wait for a response from Apple before we add complexity to the build system. Optional dependencies like this cause real pain integrating with package managers, and we’d like to avoid it if possible.”

Any responses from Apple yet? This continues to be an ongoing issue. A few Valhalla customers per day report this issue to us, and we’d love to have a solution.


Answering my own question… I found a way to prevent linking to CoreAudioKit.framework when using CMake. It requires patching a function in JuceModuleSupport.cmake:

function(_juce_link_frameworks target visibility)
    foreach(framework IN LISTS ARGN)
++          if (NOT framework STREQUAL "CoreAudioKit")
                find_library("juce_found_${framework}" "${framework}" REQUIRED)
                target_link_libraries("${target}" "${visibility}" "${juce_found_${framework}}")
++          endif()
            # CoreServices is only available on iOS 12+, we must link it weakly on earlier platforms
            if((framework STREQUAL "CoreServices") AND (CMAKE_OSX_DEPLOYMENT_TARGET LESS 12.0))
                set(framework_flags "-weak_framework ${framework}")
                 set(framework_flags "-framework ${framework}")

            target_link_libraries("${target}" "${visibility}" "${framework_flags}")

This will prevent adding the framework to any target. Due to how CMake works with the modules, I couldn’t find a way to prevent adding the framework for just some plugin formats like with ProJucer.
This does break Standalone and probably AUv3 (not tested) as CoreAudioKit is required for Bluetooth midi pairing. If Bluetooth support is disabled by patching juce_mac_BluetoothMidiDevicePairingDialogue , Standalone can be built again without bluetooth midi support. Which is what I’ll do until Apple does fix this for real - or 10.11 and 10.12 have become really obsolete. I don’t believe there will be an official fix :frowning: .

We have had some responses from Apple and we will update this thread when we have information we can share. It looks like progress is being made. Apologies for the vagueness.


Any news?


I can confirm this fixed it for a user.

What’s the down side of this?

1 Like

At the moment, none that I know of.
But tomorrow’s a new day and Apple might add an assertion that a library isn’t loaded twice, which will cause this to fail.