There is not a specific JUCE method to read and write to the security group, no. You have to dip in to Obj-C++ to get the URL, and turn it in to a File. See my reply above from Dec '17 with the appropriate Obj-C code. We still use that, more or less, in all our shipping iOS products. Don’t forget to change your file type to Obj-C++ for the file that includes this stuff.
1 Like
Thanks Chris! I hope that’s something that will be implemented in JUCE in a near future because that’d be my first case where I’d have to manually address a missing platform dependent feature in JUCE. Do you know if implementing your code as a module would eliminate the hassle of having to change the compilation behaviour to Obj-C++ each time the project is updated in the Projucer? Thanks.
You don’t need to do the renaming the file to .mm thing. Just add a separate objective C(++) file (.m or .mm) with a lone function (with a C style interface) in it that you can call from your C++ code elsewhere. That function can call the Objective-C stuff because it’s in an objective C compilation unit. You need to declare the function and mark it as extern in the C++ file where you need to call it.
2 Likes
You kind of do, because there’s no way to set a file to load in the OSX version of the project but not the Windows version. If you’re only doing iOS, knock yourself out, but if your plug is cross-platform, you have to do it my way because VSE will choke on an .mm file.
(note that I would be pleased to find out I’m mistaken here; someone is welcome to correct me.)
IMHO, real question is: shouldn’t we encourage JUCE devs to implement this? They already added App Group support in the Projucer (thanks to related conversations), but, correct me if I’m wrong, is it actually used for something from within the JUCE API? If your code (that’ll I try in the next few days) is that short and simply allows to get a path to a shared location across apps within an App Group, why not?
I’m not sure why .mm files show up in the VS project at all…IMO that shouldn’t happen.
I use JUCE modules to get around this, and haven’t run into any problems with this approach:
- You can put a .mm file next to your module’s main .cpp file. Both have the same name (except for the file extension). The .mm file is only compiled on macOS and iOS. For example, the
juce_coremodule does this. - If you want a .mm file to compile on iOS only (not on macOS), name it mymodule_iOS.mm. You can do this for other platforms as well. A file ending in
_iOS.mmshould definitely not end up in your VS project.
1 Like
+1 on having a method in JUCE to allow auv3 and the main app to read and write data and share it between them easily. I’ve also spent a full day trying to get this to work and I don’t seem to be able to do it - probably for the same reasons as mentioned in this discussion…
2 Likes
Hi @t0m , any chance you could tell us more about this possibly added to JUCE? After the added support for App Group within the Projucer, this really seems to be the next thing to consider, IMHO.
Thanks!
Related topic: Auv3 / iOS / native file browser issues / bug?
+1
Perhaps as File::getSpecialLocation(File::iosSecurityGroup) or something similar, reading off what has been specified as the App Group in the Projucer, with an assert that the group is specified and that we only call it from iOS?
2 Likes
+1 and bump 
not sure if this has been implemented but it does not seem so. In the process of setting up the Obj-c workaround above but would love some juce 6 to the rescue …
EDIT: another possible user preset road ahead would be for juce to support the ‘shared user presets’ feature
https://developer.apple.com/documentation/audiotoolbox/incorporating_audio_effects_and_instruments
Don’t know how painful that would be, but maybe it’s a more “official” way than working around with file paths and security groups
The Shared User Presets is problematic because it is a “pure” AU preset model. For those of us that also sell desktop products, it is essentially useless.
Having said that, I’ll agree that it’s high time this was an auto-created location. If the groups box is checked, it should be made and available.
4 Likes
Yep I agree , and also a way of saving user presets is always there via the host. Let’s also see what happens this next wwdc and iOS 14 : maybe it doesn’t even stick. If it does tough It should be supported by juce at some point
Is this on the roadmap? Would be extremely useful right now!
2 Likes
+1
These issues have been reported for about 3 years how; is there someone from the JUCE team who knows whether this will be implemented, or is at least on the back log?
3 Likes
+1
For the time being, getting the path can be made a bit simpler and less crazy than how @crandall1 did it (I mean the magic .substring(6)). Something like this (in a .mm file):
#if JUCE_IOS
#import <Foundation/Foundation.h>
juce::File getAppGroupContainerLocation(const juce::String& appGroupID) {
auto fm = [NSFileManager defaultManager];
auto path = [fm containerURLForSecurityApplicationGroupIdentifier:juceStringToNS(appGroupID)].path;
return juce::File(nsStringToJuce(path));
}
#endif
(You can see how juceStringToNS() and nsStringToJuce() are implemented in juce_core/native/juce_osx_ObjCHelpers.h and do the same, or, if your .mm doesn’t use ARC, perhaps just include the helpers and use those)
and in the corresponding .h:
#if JUCE_IOS
juce::File getAppGroupContainerLocation(const juce::String& appGroupID);
#endif
Then the header doesn’t expose any Objective-C symbols and you don’t have to name .mm something that isn’t iOS/macOS-specific.
However, I’m not sure you can avoid hardcoding the app group identifier somewhere in the code, unless it’s derived from the bundle identifier, but then it can be as error-prone as hardcoding.
2 Likes
Awesome, thanks @amethystdeceiver!
Got it working now! We can derive the app group ID from the plugin name itself fortunately, so no hardcoding necessary. It would be awesome however if the projucer could define the app group ID in JucePluginDefines.h (it is set in the projucer itself already anyway).
1 Like
Right! JucePluginDefines.h would be the proper way as far as I can see. Otherwise we still might change it in one place and forget to change another, even if derived from something.
Amazing, thanks! I’ll use this for the time being but would love it if this/something similar can be brought in to juce!
1 Like
Yeah, I’ve long since moved to a more sophisticated .mm include that is more or less what @amethystdeceiver put up.
But the point is still solid. This should be part of JUCE. I’m puzzled as to why it isn’t by now. This is something nearly every iOS AUv3 needs.
6 Likes
Can’t agree more