I have an app that has had no issues running on x86 or M1 when built as Universal. Today, it is throwing fits on my m1 Mac mini. Right of the bat it errors out saying It can’t write to a data folder that the app uses saying it’s read only. I checked the folder and it is not read only. I haven’t had this in the past with previous Xojo versions. Is this something anyone has seen? I’m not sure if this is a Xojo issue or something else that may have changed somewhere.
My guess is the following…
But this is potentially a bit more clear…
https://www.mothersruin.com/software/Apparency/faq.html
(see Ad-hoc signature)
Which also links to Apple which is very clear…
My hunch is wrong. I just tried to duplicate this with a new Xojo app, not signed and running on another computer and it runs fine with the ad-hoc signing.
Its not read-only to you, but it may be read-only to your app if it has been translocated.
Drag it to the desktop and leave it.
Then drag it to applications and try again.
If that fails, go to settings, privacy, and give it full disc access, maybe?
1 Like
Hi Jeff, thanks for you response. These tips did not work.
I did find something interesting though. The app and its files had been zipped up and put on my Google drive to make available to a new user. This issue was pointed out to me and I downloaded, unzipped the file and I had the same issue.
I then simply copied the folder from my x86 Mac to my M1 Mac mini and it worked just fine. So now the question is, was it affected by the zip/unzip process, the Google Drive or a combination of both. I’ve never had this issue before.
In any case, I’m going to do some more testing to try to isolate it to where the issue occurs so I can figure out how to proceed to a solution.
I just tested the zip file and it works fine. When I download the same zip file from Google Drive, unzip and try to run it, I get the message that Apple can’t verify it. If I run anyway, it starts having other issues. Still looking into it.
It was affected by being a download from the internet. This causes the translocation security feature Jeff mentioned.
With Macs, there are right and wrong ways to access FolderItems. How are you acquiring the FolderItem for this data folder? Where is it located?
Some “zips” breaks apps for sure (lose some properties needed by the Mac). How are you zipping it? Prefer DMG to pack your app.
I have a folder on the desktop that I put the app and its files. There is a data folder in there that I have the a number of methods that access the folder for read or write. Here’s how I access it.
var f as New FolderItem
f=app.AppTopFolder
f=f.child(“ABData”).child(“contactlist.csv”)
That’s a recipe for headaches.
As far as zipping it, I’m having the Mac compress it which results in the zip file. For this particular case, a DMG is not ideal as I have this package setup with the windows and linux versions as well.
You can’t assume you have access to the Desktop in Mac applications. You need to move your data storage to your own child folder of SpecialFolder.ApplicationData.
You can create a central DataFolder as FolderItem function like this to simplify things, but this is my recommendation:
// This should match the bundle identifier you have set up in the build settings
// Bundle identifiers should be domains that do actually exist and can be used to locate / contact you
var fData as FolderItem = SpecialFolder.ApplicationData.Child("com.mydomain.myapp")
if not fData.Exists then
fData.CreateFolder
end
return fData
Edit: Re-reading your post, it also appears that you’re assuming access to files located next to the app, which you cannot do while Translocated either. If your app is code signed, notarized, and not Translocated, you can – but not until all three of those steps are satisfied.
There are some special features that must be selected to a zipped Mac App work:
zip -r -y -9 MyAppPack.zip My_App.app
Recursively pack all, store symbolic links not a copy of the pointed file, best compression.
2 Likes
It turns out the the issue was that the Quarantine Bit was being set during the download and MacOS would not let it run. With the bit not set, the software runs fine on both x86 and M1 systems after doing the “Open Anyway” from the security options.
It looks like I’ll be getting a developer account set back up that expired a few years ago.
Thanks all for the feedback and suggestions.
2 Likes
Add another packaging step doing a preventive clean up before zipping it too:
sudo xattr -cr My_App.app
zip -r -y -9 MyAppPack.zip My_App.app