Plug-in built with Xcode 11 fails to load on Yosemite (10.10)

Since ADC is over now, have you gotten the chance to take another look at this yet? I have the exact same problem for some customers and I can’t reproduce it myself. I don’t have 10.10 either unfortunately, otherwise I would’ve tried debugging it myself.

1 Like

Apple is likely to start pushing use of the newer SDKs with the changes to notarisation coming in Jan 2020 (those from which we were given temporary reprieve), so these findings are quite concerning. Looks like if hosts are going to be moving onto SDK 10.15 to get through notarisation, we could have some problems on Yosemite even if we’re building plug-ins with 10.14 SDK. If the fix is to build with SDK 10.13, this is likely to give us problems notarising.

1 Like

In my company, we notarize software that is built with the 10.11 SDK (using Xcode 10.1 on macOS 10.13.6). This guarantees us full compatibility with the minimum version of macOS that we support (10.11.6). So far, Apple hasn’t pushed us to use a more recent SDK.

Sure, and this is possible currently because Apple relaxed previously much stricter notarisation requirements in advance of Catalina’s release to ease the transition to notarised distributable software. They indicate that this act was strictly time limited, hence my concern and eagerness for a resolution to the matter in this post.


A news on this? It seems urgent as January is getting really close. The crash log earlier looks like there’s a problem in what used to be called Component Manager in OS X and has been partially removed - not without causing issue to us AU devs. Unfortunately I no longer have 10.10 installed so I can’t help in the search to the root of the problem but it sure looks like this is going to be painful because it’ll make it impossible to have AUs/Installers that run notarized on 10.15 and still load on 10.10.

1 Like

Anyone logged this at Apple? Any radar so we could maybe pile up on the issue?

1 Like

I’d pile up instantly if I knew the issue was in the 10.15 SDK. But it could also be caused by something inside JUCE. The likelihood of Apple fixing anything before January is basically zero, so the best solution would be to find a way to work around this problem by patching JUCE.

Has anyone with access to both 10.15 and 10.10 machines tried building any of the apple examples using the 10.15 SDK to try and load them on 10.10? If that doesn’t work then we absolutely need to file a radar.

Ah ok, tom already did that and it didn’t work… => d’oh!

1 Like

Is it true that software has to be built against the 10.15 SDK to pass the notarisation in 2020 in catalina?

I wasn’t able to find that requirement.

We don’t know yet. They’ve not re-announced what the policy will be once it’s reinstated. It’s quite difficult to make plans based on that, and given that we have a known problem here, there’s scope for some more choppy waters on the notarisation topic ahead.

Here’s a very simple app that won’t run on 10.10 when built with the 10.15 SDK:


#import <Foundation/Foundation.h>
#import <AudioToolbox/AudioToolbox.h>

int main(int argc, const char * argv[]) {
    AudioComponent comp = NULL;

    for (;;) {
        AudioComponentDescription desc;
        memset((void*)&desc, 0, sizeof(desc));

        comp = AudioComponentFindNext(comp, &desc);
        if (comp == NULL)

        if (AudioComponentGetDescription(comp, &desc) != noErr)

        CFStringRef cfName;
        if (AudioComponentCopyName(comp, &cfName) == noErr) {
            NSLog(@"%@", (__bridge NSString*)cfName);

    return 0;

The runtime error message is:

dyld: lazy symbol binding failed: Symbol not found: _AudioComponentFindNext
  Referenced from: /Users/tom/workspace/./AUScan
  Expected in: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox

dyld: Symbol not found: _AudioComponentFindNext
  Referenced from: /Users/tom/workspace/./AUScan
  Expected in: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox

Trace/BPT trap: 5

So it looks like there’s a mismatch between what’s present on 10.10 and what the 10.15 SDK is expecting. Running nm on /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox on the 10.10 machine gives us

000000000000e89e T __AT_AudioComponentFindNext

If we look at the contents of MacOSX10.14.sdk/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox.tbd then we will find an entry for _AudioComponentFindNext in the list of symbols for /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox.

However, if we look at what’s inside MacOSX10.15.sdk/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox.tbd then the only _AudioComponentFindNext entry is in the listings for /System/Library/PrivateFrameworks/AudioToolboxCore.framework/Versions/A/AudioToolboxCore.

I’ve not quite got the full picture, but it suggests that the location of the symbol has changed in the latest SDK and it’s broken backwards compatibility.


Interesting, thanks Tom! So this is most definitely an Apple issue then, right?

The example in my previous post is unrelated to JUCE.

Are you planning to notify Apple about the situation you have found here?

Yep, will do that today.

It seems that most DAW makers are building against an older SDK.

Very interesting to see Logic is built against 10.13, it could be a sign Apple considers that an acceptable vintage for notarisation in 2020 if it satisfies their internal build processes. Having to second-guess this kind of stuff is pretty frustrating.

1 Like

Wow… interesting fix! How did you figure out how to solve this issue? Is it a bug in the SDK?

1 Like

Thanks @t0m, can you also explain what needs to be done to solve the issue in projects not maintained with Projucer?

Apple got back to me via Feedback Assistant.

The AudioUnit framework needs to be linked before the AudioToolbox framework if you are building against the 10.15 SDK. This is not a requirement when building against any other SDK version.