we’ve been receiving reproducible bug reports from users that updated to the latest macOS 13 Beta on M1 systems related to file system errors.
It seems like our Plug-ins that are loaded into ARM-native DAWs are not able to access the file system, specifically the ~/Library/Application Support folder cannot be written to or read from. This behaviour seems to be consistent across Plug-in Formats and DAWs (tested with Reaper and Logic).
Obviously I’ve checked the permissions of the folder: even with 777 permissions the plug-in is not able to read/write there, manually creating the required folder/data with 777 permissions does not resolve the issue.
I tried to give Reaper the Full Disk Access permission via the System Preferences, without success.
As this happens with Logic leads me to believe that this is not a permission/entitlement issue, I’d assume that Apple would check whether its own DAW has the correct permissions.
Furthermore, I can see that a natively-started Reaper instance is able to create folders in ~/Library/Application Support.
However, I noticed that if starting the DAW via Rosetta resolves the issue, then the plugin can access the file system normally.
Considering all this I think that this might be a problem with JUCE itself.
Would it be possible for a JUCE-dev to check this out?
I’m confused by these statements, could it be that you meant that the natively-started Reaper instance is not able to create those folders, whereas the instance started unders Rosetta is capable to create them?
Sorry I didn’t communicate this properly:
Reaper itself is able to create and access its own folders under ~/Library/Application Support, both if started natively and via rosetta. However, the plugin loaded in reaper is not able to create folders in the same directory if Repaer is started natively, but the plugin is able to create and access the folders if Reaper is started via Rosetta.
We are not specifiying any sandboxing options, so these should be at the default values- previously this has never caused problems.
I was under the impression that this does not really matter for audio plugins, as they are restricted to the permissions of the DAW anyways- is this correct?
I also checked for changes to the entitlements/sandbox system in the macOS 13 release notes, but did not find anything related to this issue.
I’m currently building a small example plugin to see whether the situation is the same on macOS 13 on Intel, and if the folders can be accessed correctly using the C++ Filesystem library, I’ll post the results soon!
Alright, I’ve found the error- turns out it was pretty trivial in the end.
Turns out macOS 13 isn’t yet present in juce::SystemStats::OperatingSystemType, therefore juce::SystemStats::getOperatingSystemType() returns OperatingSystemType::unknown, and we had a function in place that set up some paths depending on the OS that failed as a result of that.
What is strange though is that when running Reaper via Rosetta and loading the plugin, it reports Mac OSX 10.16 aka juce::OperatingSystemType::MacOSX_11 - this is why the code in question continued to work in this situation.
However, investigating this I’ve encountered some strange behaviour regarding macOS version reporting:
I’ve used the CMake example audio plugin as starting point, building it as VST3, AU and Standalone, adding a line that prints the result of juce::SystemStats::getOperatingSystemName().
Machine 1 has an Intel processor running macOS 12.0.1.
Standalone: Mac OSX 12.0.1
auval: Mac OSX 12.0.1
Reaper VST3/AU: Mac OSX 10.16
AULab: Mac OSX 10.16
Machine 2 has an M1 process running macOS 13.0.
Standalone Native/Rosetta: MacOSX 13.0
auval Native/Rosetta: Mac OSX 13.0
Reaper VST3/AU Native: Mac OSX 13.0
Reaper VST3/AU Rosetta: Mac OSX 10.16
AULab Rosetta: Mac OSX 10.16
What is striking is that I’ve looked at the code that queries the version number, and from what I understand this is basically a simple grep of /System/Library/CoreServices/SystemVersion.plist, this means some virtualization/sandboxing layer might interfere with this information.
The version number returned depends on the SDK you are building against. If you are building against the current SDK, you get version numbers like 12, 13, etc. If you build against an older SDK you get 10.15, 10.16 etc. It looks like your Intel version is using an old SDK while your ARM version is using a new SDK.
I don’t think that this is the case here.
The plugins that I’ve tested with are universal binaries built against a macOSX 12 SDK.
Also, as I’ve described above, the method that is used to detect the OS version is here, I don’t think that this has something to do with the SDK version that is used.