Here's the problem I'm trying to solve: Create an iOS app which can scan the Downloads folder (where airdropped audio files arrive), identify audio media files, and play them, retaining some of its own metadata about them (basically, create textual notes mapped to timestamps and store that information in the apps own storage). I am not able to access that folder. I am able to get a path from NSSearchPathForDirectoriesInDomains(FileManager.SearchPathDirectory.downloadsDirectory, FileManager.SearchPathDomainMask(arrayLiteral: FileManager.SearchPathDomainMask.userDomainMask), true) or a URL from NSSearchPathForDirectoriesInDomains(FileManager.SearchPathDirectory.downloadsDirectory, FileManager.SearchPathDomainMask(arrayLiteral: FileManager.SearchPathDomainMask.userDomainMask), true) but let fileUrls = try fileManager.contentsOfDirectory(at:downloads, includingPropertiesForKeys: []) fails with an error that the folder does not actually exist, with or without a call to downloadsUrl.startAccessingSecurityScopedResource(). Determining whether this is a permissions issue, or if I'm getting a URL to an application-container local folder that has nothing to do with the one I am looking for is compounded by the fact that if I set the build setting Enable App Sandbox, then deployment to my phone fails with Failed to verify code signature. I have spent hours trying every possible combination of certificates and deployment profiles, and ensured that every possibly relevant certificate is trusted on my phone. Disable app-sandbox and it deploys fine, either with automatic signing or an explicit cert and profile. I have an entitlements file with the following - though, without the ability to enable app sandbox and run it on a phone with actual contents in the downloads folder, it is probably not affecting anything: <key>com.apple.security.files.downloads.read-only</key> <true/> <key>com.apple.security.files.user-selected.read-only</key> <true/> <key>com.apple.security.app-sandbox</key> <true/> So, questions: Should the URL returned by the above call be the Downloads/ folder airdropped to in the first place? Or is it a URL to some app-local folder that does not exist? Does the entitlement com.apple.security.files.downloads.read-only even allow an app to list all files in the downloads directory (presumably asking the user's permission the first time), or does the permission only get requested when using a picker dialog? (the point here is to find any new audio files without making the user jump through hoops) If I could get it deployed with app-sandbox enabled, would the above code work? Backstory: I'm a software engineer, audio plugin author, Logic Pro user and musician. My workflow (and probably many other Logic user's) for work-in-progress music is to airdrop a mix to my phone, listen to it in a variety of places, make notes about what to change, edit - rinse and repeat. For years I used VLC for iOS to keep and play these in-progress mixes - you could airdrop and select VLC as the destination (yes, Logic can add to your Apple Music library, but trust me, you do not want 20 revisions of the same song cluttering your music library and sync'd to all your devices). Last year, the behavior of Airdrop changed so that the target app for audio is always Files, period, wrecking that workflow. While I eventually discovered that, with an elaborate and non-obvious dance of steps, it is possible to copy files into VLC's folders, and make them available that way, it is inconvenient, to say the least - and VLC is less than fabulous anyway - it would be nice to have an app that could associate to-do notes with specific timestamps in a tune, A/B compare sections between old and new versions and things like that. So, figuring sooner or later I was going to get into a car accident futzing with the Files app to listen to mixes while driving, perhaps I should write that app. But the ability to do that at all relies on the ability of an app to list and access the Downloads folder airdropped audio files land in (assuming the user has given permission to access it, but that should be needed once).

After investing more than a week into getting a bunch of audio unit projects converted into app + appex + framework, they all are now correctly loaded in-process in the demo host app that is part of Xcode's template. However, Logic Pro adamantly refuses to load them in-process. Does Logic Pro simply not do that ever, or is there some hint or configuration my plugins need to provide to enable that? If it is unsupported, will it be supported in some future version of Logic? The entire point of investing that week was performance, which is moot if it is impossible to test the impact of loading in-process in a real-world usage scenario.

I've got a bunch of AudioUnit projects approaching release, and am attempting to build an installer for them. All are based on the AudioUnit template in Xcode 14. What actually governs how the system detects an AudioUnit? The instructions I have seen say that the built .appex should be renamed to have the extension .component and installed into /Library/Audio/Plug-Ins/Components/ - great, I am able to build a signed installer that does that (i.e. strip out the built Application project that is part of the AudioUnit template but useless to, say, a Logic Pro user), include the .appex that declares the plugin and embeds a Framework that contains the actual code (so it can be loaded in-process). auval -l does not show it after running the installer, nor does Console show anything logged suggesting that it was found but malformed or something like that. Meanwhile, simply building the project causes auval -l to show an install of it in the build directory, and I have noticed that if I delete that, auval -l would still show the plugin installed, but now in the location I exported an archive of the project (!!). What black magic is this? However, deleting both the recent build and the archive, after running the installer, and there is no indication that AudioComponentRegistry even sees the copy of it in one of the two locations actually documented to be valid install locations for an AudioUnit. I have, however, installed one third-party free AUv3 which installed into /Library/Audio/Plug-Ins/Components/ Am I misunderstanding something about how this works? Is there some string other than AudioComponentRegistry I should filter on in Console that might provide a clue why my AudioUnit installed there is not picked up? Must I ship the semi-pointless Application that is part of the Xcode template project, and whatever magical mechanism detects it when I build will work its magic on end-users' machines? Or could the problem be that the Framework with the actual code under Contents/Frameworks inside the audio unit, rather than installed independently into /Library/Frameworks?

I've got a bunch of Audio Units I've been developing over the last few months - in Xcode 14 based on the Audio Unit template that ships in Xcode. The DSP heavy-lifting is all done in Rust libraries, which I build for Intel and Apple Silicon, merge using lipo and build XCFrameworks from. There are several of these - one with the DSP code, and several others used from the UI - a mix of SwiftUI and Cocoa. Getting the integration of Rust, Objective C, C++ and Swift working and automated took a few weeks (my first foray into C++ since the 1990s), but has been solid, reliable and working well - everything loads in Logic Pro and Garage Band and works. But now I'm attempting the (woefully underdocumented) process of making 13 audio unit projects able to be loaded in-process - which means moving all of the actual code into a Framework. And therein lies the problem: None of the xcframeworks are modular, which leads to the dreaded "Include of non-modular header inside framework module". Imported directly into the app extension project with "Allow Non-modular Includes in Framework Modules" works fine - but in a framework this seems to be verboten. So, the obvious solution would be to add a module map to each xcframework, and then, poof, they're modular. BUT... due to a peculiar limitation of Xcode's build system I've spent days searching for a workaround for, it is only possible to have ONE xcframework containing a module.modulemap file in any project. More than that and xcodebuild will try to clobber them with each other and the build will fail. And there appears to be NO WAY to name the file anything other than module.modulemap inside an xcframework and have it be detected. So I cannot modularize my frameworks, because there is more than one of them. How the heck does one work around this? A custom module map file somewhere (that the build should find and understand applies to four xcframeworks - how?)? Something else? I've seen one dreadful workaround - https://medium.com/@florentmorin/integrating-swift-framework-with-non-modular-libraries-d18098049e18 - given that I'm generating a lot of the C and Objective C code for the audio in Rust, I suppose I could write a tool that parses the header files and generates Objective C code that imports each framework and declares one method for every single Rust call. But it seems to me there has to be a correct way to do this without jumping through such hoops. Thoughts?