macOS version detection does not work reliably


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?

Best, Stephan

What I would do as a fist step is open and look for related errors and/or faults. Did you try this already?

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?

Can other folders like ~/Music/ can be accessed?

If yes, sounds like the plugins running in the macOS Sandbox. Does disabling “Use App Sandbox” in Projucer makes a difference?

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!

1 Like

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.

Maybe @reuk wants to take a look at this?

1 Like

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.

You’ve probably read this article already, but posting it here for future readers.

@reuk Don’t want to bother you too much, but I think at least macOS 13 should be added to the OS list, even if you decide to not investigate the version detection in rosetta :slight_smile:


That’s added here:

1 Like