SpecialFolder.SharedApplicationData and Ventura

Hey all,

According to the Xojo Docs, SpecialFolder.ShareApplicationData should point to /Library/Application Support but in Ventura I am seeing that is not the case. Instead I am getting /Users/UserName/Library/Application Support

Anyone else see this? I’m thinking I need to report it as a bug.

Sounds like Apple changed something and didn’t tell anyone.

1 Like

Yes its broken in Ventura.

Sounds like Apple. Making the Mac less Mac-like with each iteration of OS X. Frankly I think Steve Jobs is rolling over in his grace.

I will submit a bug report.

2 Likes

This does appear to be a Xojo bug however. Using declares it does point to the correct location.

Here’s a sample project I used to test it:

https://www.dropbox.com/s/pbruvgszjybr7x4/NSFileManagerTest.xojo_binary_project?dl=1

If you choose “ApplicationSupport” for Directory and “Local” for Domain, Ventura does give you the correct directory.

1 Like

Thanks, Greg. Are declares really needed/used in Xojo’s code? I figured that you would more likely use:

Dim f as FolderItem = SpecialFolder.ApplicationData

was just using:

Dim f as FolderItem
#If Target MacOS Then
   f.ShellPath = "/Library/Application Support"
#ElseIf Target Windows Then
.....
#End If
Return f

https://tracker.xojo.com/xojoinc/xojo/-/issues/71552

I wouldn’t use a text literal. Apple could easily move that location and your app could stop working.

Think about what happened when APFS came along. Now there’s two Applications directories. One that’s protected on the system volume and one that’s for user-installed applications. I wouldn’t put it past Apple to make the same distinction for its own apps one day.

The other difference with the example project I supplied is that you have access to all four domains (User, Local, Network and System) because which domain you use changes where the files are. If your user were using a mac that’s managed by JAMF, the location of user files could be vastly different than what is on your developer machine and only the system calls will tell you where that is.

1 Like

While that’s true, SpecialFolder.ApplicationData is worse while it’s broken.

1 Like

Actually, ApplicationData is working fine, it’s the SharedApplicationData item that’s borked.

What’s strange is that in the bug report Robin is saying he sees it working correctly. I’m going to have to try his example.

Robin may be using a newer Xojo version.

Greg,

I’m interested in how you are seeing this “bug.” I’ve found it was a problem in my code. Here’s what I have in a test project:

Dim f as FolderItem 


#IF TargetLinux or TargetArm Then
  f = SpecialFolder.ApplicationData.Child("JustAddSoftware")
#Else
  fr = SpecialFolder.SharedApplicationData.Child("JustAddSoftware")
#Endif

f.open

Since Xojo is now allowing 64 bit ARM compiles and since I am running on Apple Silicon, the TargetARM directive takes over…

How are you seeing it manifest itself?

I’m seeing things work correctly now that I’m not pointing to a different directory with the TargetArm directive. I originally put that in there because of RaspberryPi support.

3 Likes

I did not check your code and took your word for it.

1 Like

Ok. Well, it was my screw-up

Fair point; I was reading too fast. So I repeat myself with the correct item:
While that’s true, SpecialFolder.SharedApplicationData is worse while it’s broken. :wink:

It’s not broken. I am. :smiley:

The problem was that I had a “TargetARM” directive in my code to use a different directory. This was originally put in my code for RaspberryPi devices. But now that Xojo supports 64 bit compilation on all ARM devices, TargetARM is now Xplat. So it includes RaspberryPi, Linux, Windows ARM, iOS, Apple Silicon, etc.

1 Like