[Solved] My homemade V3 AudioUnit could not be loaded on GarageBand on macOS 10.13

NOTE: This is the English version of my Japanese article.

- 2017/10/14 NOTE -
I have posted a solution.
- 2017/10/14 End of NOTE -

summary:
It seems that my AU needs to support "in-process loading" to use in GarageBand.
For that, the all of AU implementation should be moved to a homemade cocoa framework.

Details:
When I was testing my homemade AU on macOS 10.13, I found that GarageBand can not load my AU normally.
Although the AU was displayed in the list, a surprise mark was displayed when my AU was selected.

Even if you click it, AU's view was not displayed.
And, the effect functionality was also worked.

Although I can not identify the cause yet, it is probably because it is because my original AU can not handle in-process reading.

Reading logs in Console.app, I confirmed that GarageBand was outputting an error:

254: Extension <private> advertises loadable bundle <private>, but we couldn't find it

To solve this error, I rechecked build settings, Info.plist, Sandbox related settings, etc...
But I could not solve it.

In subsequent investigation with my AU containing app, if kAudioComponentInstantiation_LoadInProcess is specified as the second argument of + [AVAudioUnit instantiateWithComponentDescription: options: completionHandler:],
I found that similar errors are displayed.
Apparently, GarageBand seems to be trying to load my AU in-process.

Supporting in-process loading:
It seems necessary to provide all the implementation of self-made AU as .framework in order to make homemade AU support in-process loading.
The crew is commented out in FilterDemoExtension.m in the sample code "AudioUnitV3ExampleABasicAudioUnitExtensionandHostImplementation":

To facilitate loading in-process and into a separate extension process, the .appx main binary cannot contain any code. Therefore, all the plugin functionality is contained in the FilterDemo.framework and the .appx Info.plist contains an AudioComponentBundle entry specifying the frameworks bundle identifier.

In fact, FilterDemoExtension.m has only a function called dummy (), and all AU implementations seem to be thrust into FilterDemoFramework.framework.

From now on, when we created the new V3 AudioUnit project, it may be better to use this sample code as a template.
I confirmed that the sample AU (FilterDemo) could be used in GarageBand without problems.

Also, as you can see in this comment, bundle identifier seems to need a bit of ingenuity,
I do not know well so I would like to investigate in the future.
It seems that bundle identifier in the sample code was changed compared to older one.
So, it may be necessary change to support in-process loading.

To be continued...

--
I'm looking for job for macOS/iOS application development by outsourcing.
For details, please visit my web site.