Should I just give up on releasing a sandboxed plugin on Mac?

So I’ve been working on a sampling engine plugin for about six months. The plugin is available for Mac (VST, VST3, AU, Sandboxed AUv3, and Sandboxed standalone), Windows (VST3), and iOS (app, Sandboxed AUv3). Of all the engineering challenges that the project has thrown at me, the thing that has given me the most headaches has been sandboxing on Mac and iOS. Here’s why:

My sampler’s sample libraries consist of multiple files: a core XML file (that contains info on which samples to load and how the engine should make use of them) and a bunch of random assets (WAV files, images, etc.). Users need to be able to click on a preset (using the File open dialog), the engine needs to load that XML, and then the engine needs to find and load the files referenced in that XML file. It’s like SFZ format, but it’s slightly different. Anyway, the way Apple sandboxing works, only files that were specified by the user can be accessed by a sandboxed app. In other words, after a user chooses an XML preset file, the engine no longer has access to the WAV files referenced in that XML file. So here are my options:

  1. The app has access to any file in the user’s ~/Music directory. The app also has access to any file in the user’s Samples directory (this is a directory that I force them to create when the app first runs). I store a URL bookmark to this directory which I reactivate every time the app starts up. So my option here is this: If they try to open a file that isn’t in their ~/Music or Samples directory, I pop up a warning that says “you should move this into your Samples” directory.

  2. I could theoretically make them select the parent directory that contains the XML file. This would allow me to access any files under the tree, but this is weird and unusual request from an app to make. Also, what if there are multiple XML files in that directory, I would then need to have a secondary dialog that would pop up and asks them which preset they want.

  3. I have created a .dsbundle package datatype. This allows macOS to display an entire directory as a single file. This would be my favorite solution except that my app also supports Windows. Windows would display these .dsbundle packages as regular directories which means I would need to have Windows users use an ugly directory selection dialog in order to open .dsbundle packages. Having a different user experience for Mac and PC strikes me as really crummy.

  4. And this final one: I could give up on having an AUv3 on Mac. I could simply ship a non-sandboxed AU which seems to just work and allow them to load XML and accompanying files.

My question is this: Which of these sounds best? I’m personal torn between #1 (a short informational message to my users) and #4 (giving up on the format). Should I just give up on AUv3 for Mac? Is there any reason to support this format? On iOS I have no choice and will continue, but on desktop Mac? By the way, Logic users are very important to me. Is there a chance Logic may up its requirements and force everyone to release in sandboxed AuV3s? Because if so, I definitely want to ahead of the curve on that.

1 Like

Possibly displaying my ignorance here but what about putting all the files in a .zip or .7z file? Doesn’t even need to be compressed.


Good call. Yes, that was secret option no. 5, which I failed to mention. :slight_smile: The app does actually support unzipping archives, and this does bypass the sandboxing issues. The downsides are that in a situation where a developer is making frequent changes to a file to test it out, they have to zip and rezip the file every time, which is cumbersome and time consuming. It never occurred to me to zip files without compression, though…

Very interesting topic.
Unfortunately I don’t have an answer.
But I am going to follow this closely, because I am programming something similar.

1 Like

Maybe your product could also allow the selection of a directory, as per point #2 in your original post, and that feature can be used while authoring the presets until they are read for being ZIPped and released.
If you are not comfortable with leaving that feature in the plug-in for the final user, you can allow directory loading only in debug build, or only when a modifier key is pressed, or only when a certain file is present on disk… things like that


This is probably the route I would take. Have the code that selects a directory wrapped in #if JUCE_DEBUG and use the zip method for release builds.