App Group Folder Access

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_core module 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.mm should 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 :slight_smile:
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.

1 Like

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 :slight_smile:

Coming to this thread trying to figure out what’s the best path for me to share a folder with JUCE AUv3 and Standalone it seems that you need:

  • App Group ID (support by projucer/juce)
  • getAppGroupContainerLocation - not supported by JUCE.

Once I get the container location I can use it in both. is that correct?
Maybe worth adding the getAppGroupContainerLocation into JUCE with AUv3/Standalone pretty common combo.

2 Likes

Yes, that’ll do it. Until it’s part of JUCE.