Has anyone seen this behavior for JUCE auv3 plugins?
Save an xml file from within auv3 using the native iOS file browser (with app groups etc enabled). File saves fine (on ‘On my iPad’). File appears in Files.app as well.
Change something in the plugin.
Load the same xml file again; all settings are perfectly restored. All good so far.
Now close the host (Cubasis in my case) and restart it. Load your auv3 plugin, and try to load the same xml file as in step 3) above. Now all of a sudden it will not load… std::unique_ptr wi(url.createInputStream()) simply returns a null pointer.
Strangely enough, I can load that same file with the stand-alone version of the same plugin. I am using the following code snippets for loading and saving:
To load an xml file:
FileChooser myChooser("Select file:",
"*", true, true, parentComponent);
auto url = myChooser.getResult();
if (wi != nullptr)
const String s = wi->readEntireStreamAsString();
if (s.length() > 0)
if (xml != nullptr)
// Do something sensible here
Does this mean we can’t use the native file browser for auv3? If I switch back to the JUCE file browser, and always read/write the xml file from within the documents folder of the auv3, it does work consistently.
AUv3 plugins have their own directory structure that is sandboxed; if you’re using the Files trigger (which is what the native chooser is) you’re saving to the standalone’s directory structure. The AUv3 can’t actually see that; hence the nullptr.
You have to save to and load from the security group, which is a third (!!!) tree that both the standalone and AUv3 can see.
(As to why it persists after the save, but not the re-open, no idea. Strange are the ways of the URL.)
Yes; even just a simple function that would return the path to the folder of the security group (based on properties set in projucer) would already be a big help so we know where to read and write files for iOS. @crandall1 has already supplied the code to get that path; as far as I can see it only needs integration in the JUCE framework to get that to work in an easy way?
@crandall1 I think I get it but this confuses me quite a bit.
So is it true then that the auv3 can write to the standalone’s directory structure (my tests indicate that this works perfectly fine, and the files written can be opened by the standalone app), but the auv3 cannot read from what it as written itself in that structure?
To the best of my knowledge, that is correct. If you write to the standalone’s “Documents” folder from the AUv3, you can not read it from the AUv3 later. If App Groups are active for the pair, the AUv3 can read from the Standalone’s bundle, but not write to it.
The AUv3 can open a Files instance (which is the native browser in iOS) and read and write to the main system file tree (assuming you have a minimum of iOS 11) and with App Groups, you can read and write to the Security group, which is the file tree that the .appex and .app share. But the AUv3 has no other file writing permissions outside of that; AUv3 are heavily sandboxed, and the system tree (via the Files app), Security Group, and its own tree (which nothing else can see) are the only places it has read and write access to.
So, for presets, best to use the security group, because both have permissions to it and both can see it at all times. You’ll need to do my Obj-C song and dance from the other thread for that. For loading and saving audio files, best to use the native browser and Files instance, because Apple doesn’t like it when you save large blobs of data in the app groups, and you run the risk of rejection, or having your folder cleaned out or not backing up.
You can read further at the links at the bottom of the screen, depending on how interested you are in learning about CoreData and iCloud. The short answer is audio recordings should not be backed up. You should only store data that the user creates and that the app can’t recreate, and which isn’t gigantic, in the backup locations.