Answering my own question to close this out: FWIW, as Quinn points out, yes, startAccessingSecurityScopedResource() is critical. Preserving access across app restarts and device reboots took some experimentation to find the right incantation of keys baked into the bookmark. The following is what I am using (some of these are particular things I need, but the security and permissions-related ones are critical): extension URL { /// Get a bookmark to a file in a folder the user has granted access to, which will /// be usable across a device reboot. func rebootSafeFolderBookmark() throws -> Data { try self.bookmarkData(includingResourceValuesForKeys: [.fileSecurityKey, .volumeSupportsExtendedSecurityKey, .contentModificationDateKey, .isDirectoryKey, .fileResourceIdentifierKey, .isUbiquitousItemKey, .ubiquitousItemContainerDisplayNameKey, .fileProtectionKey, .ubiquitousSharedItemCurrentUserPermissionsKey, .parentDirectoryURLKey, .addedToDirectoryDateKey]) } /// Get a bookmark to a file in a folder the user has granted access to, which will /// be usable across a device reboot. func rebootSafeBookmark() throws -> Data { try self.bookmarkData(includingResourceValuesForKeys: [.fileSecurityKey, .volumeSupportsExtendedSecurityKey, .contentModificationDateKey, .isDirectoryKey, .fileResourceIdentifierKey, .ubiquitousSharedItemCurrentUserPermissionsKey, .isUbiquitousItemKey, .fileProtectionKey, .addedToDirectoryDateKey]) } }

I found the culprit: session.setPreferredIOBufferDuration(0.002) Commenting out that line allows audio to play - but the system default buffer size is huge (likely to preserve battery life), resulting in an unacceptable 1/2 second delay when pausing the AVAudioPlayerNode. When I next have access to a vehicle with CarPlay I will try a few alternate buffer sizes and see if there is a happy medium - 2ms is a very small buffer size. If I discover anything useful I will post an update here. Silent failure in the face of an incompatible setting isn't really ideal, especially when the setting is named preferred which implies that if the value passed can't work, it will be ignored.

Yes, I have am testing for all of the above. The problem is not that I'm getting an interrupted ended notification (I've noticed that the end of a phone call often fails to result in one). The problem is that I am getting an interrupted ended notification when it is inappropriate. If I am playing music in my app, switch to Apple Music and play something there, and simply switch back to my app being the active one with Apple Music still playing, I should not get an interruption ended notification. The problem is that about half the time I do, and there seems to be no pattern to it. There is no path in my own code by which becoming the active application could also activate the audio session, so it seems this really is a spurious notification iOS sends on its own. Fundamentally, it would be rude for my app to hijack the audio session back simply because it became the focused app, when another app is still playing. I would like to avoid that, but I can't see any obvious way to ignore interruption-ended notifications sent by the OS by mistake, without also ignoring ones I really should process.

Hmm, well, I am as far as opening the file picker and selecting the downloads folder - but a curious thing I'd wondered about before. Where airdrops land is apparently actually an iCloud sync'd folder - selecting the right folder on my phone results in a URL of file:///private/var/mobile/Library/Mobile%20Documents/com~apple~CloudDocs/Downloads/ Attempting to read it results in The file couldn’t be opened because it doesn’t exist. Is this solvable with some additional permissions / entitlements?

Good to know. So, sans that, I assume the entitlements file is being read? While I've been doing platform-specific Apple development for a year (and was a Java guru in a former life), that's been entirely polyglot Audio Unit development in Rust and C/ObjC, so I haven't delved into the world of writing iOS apps until now. Edit: Apologies, I hadn't seen that there was more than the first two lines of your reply when I wrote that. Trying your suggestion now.

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.

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.

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?

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?