To update this with my attempts at workarounds - I've made what seems like some progress by: Adding a Framework target to the audio unit project Moving all sources to be compiled as part of that, and moving the library dependencies there Adding a custom module map that includes all of the library headers (requires including a copy of the header files in my project [!] - no idea if it will link at runtime, but usages of the libraries are no longer errors) Setting the framework project's custom module map to that Since the original Audio Unit template makes liberal use of .h files, and these are verboten in a Framework without a module map, all of those have to be added as well (I suspect adding a bunch of stuff that has no business in the public API of my plugin into it) - I tried the private module map option, which did not work. The result: The usages of my libraries are no longer errors. But imports from the C++ standard library now are - e.g. #import <span> now results in 'span' file not found. My god, what a mess this is, and why in the world is the Xcode template set up to make it as difficult as possible to turn the code it generates into something production-worthy?

Thanks. After two excruciating weeks of debugging, googling and trial-and-error, I did get this working, and am in the process of applying this approach to 13 audio unit projects, which takes a couple of hours each. As a small service to humanity, I created a demo project containing before- and after-projects plus a script that builds valid, signed installers with one-time setup in Xcode - with step-by-step conversion instructions. And I tried to carefully document the various footguns and diagnoses for the more cryptic errors you can run into, in this comprehensive github project. Two remaining issues with loading the Audio Unit in-process: Some Audio Units I have converted to be able to load in process (adding a Swift Text area to the UI to show whether they are or not). Other identically configured audio units, when running the demo app, never load in-process, although all are loaded with AudioComponentInstantiationOptions.loadInProcess. Is there any way to diagnose this? Does Logic Pro ever load AUv3's in-process? After spending two weeks to get this all right, even audio units which can load in-process in the app never load in-process in Logic Pro. Is that even possible?

I did eventually solved this - the key is, the framework needs public and private module-map files to do what the Objective C Bridging Header did for the appex project. I documented the entire process, with before and after examples in this Github Project which also shows how to script building signed installers.

For what it’s worth, I have done it - my real DSP code is in Rust, but to shorten development time when tweaking an algorithm, and the performance was fine. BUT, I was emulating what I do to make Rust callable by an audio unit - that is, everything is raw pointers and primitives, and there’s no allocations because the DSP contains no code that could possibly allocate. So it’s basically writing C in Swift. You can do it, but you can’t use any of the things that make Swift pleasant to use.