Mac OS - can't read files - codesigning, notarization,?

OK, bear with me here…I’m working on bringing a very, very old Mac OS app (from realbasic days) into the present, in order to support recent Mac OS versions (64-bit), etc. I have already:

  • got the app working on my Mac running Mac OS 11.4.
  • obtained a Developer ID Application certificate from Apple.
  • purchased App Wrapper 4 to help with the codesigning and notarization.
  • successfully (AFAIK) codesigned and notarized my app, yielding a finished ZIP archive.

The app itself was originally designed to be “portable”, in the sense that:

  • a bit of demo data is included in a “data” folder alongside the app in the ZIP archive
  • the app should be able to read/write data to this sidecar folder so that it can be easily run from anywhere, such as a folder on the desktop, a USB stick, etc.

My problem is that if I put the prepared ZIP archive on the web and download it:

  • I get a (normal) Gatekeeper prompt asking if it’s OK to run the app (and that it’s been scanned by Apple…so notarization OK). Fine with this.
  • the app runs, but is unable to read the sidecar folder. This causes all sorts of trouble.

For whatever reason, the app is not getting the permissions it needs to access the folder right beside it.

If I forcefully unquarantine the app using

xattr -r -d

then it works perfectly.

Ideas about what I’m missing or what more info I could provide in order to troubleshoot this further?

Probably app translocation; search the forum for “translocation” and you’ll find a number of posts. There are some workarounds, but the right solution is to put your data in the SpecialFolder.ApplicationData folder.

Good discussion here: App Translocation

1 Like

This is almost certainly App Translocation.

You can work around this by using a DMG file, and an Applications folder alias (like the one App Wrapper ships on). However that will also incur another round of problems, in that the Applications folder isn’t writable to apps (by default).

My suggestion is to add the demo data into the Resources folder of your application. Now you won’t be able to write to that from inside your application. If you do what @Matthew_Dinmore1 suggests, and copy that data to somewhere else that the application can write to, you should be fine. The Application Support folder is pretty much the place you should always be able to write too.

Another idea is when the customer first run your application, on the splash screen offer the option to create a demo document, let the user choose where they want to save this document, copy it from your resources folder to their chosen location and off you go.

Oh and welcome to modern macOS development.

1 Like

No kidding. As a Windows developer who literally just bought a Mac in order to revive this old project for a handful of users and landed in a mess of codesigning, notarization, entitlements, etc…UGH.

Anyway, thanks for your speedy replies, you were absolutely on the mark. I confirmed that it’s App Translocation by moving the downloaded app and the data folder into Applications and sure enough it works fine.

I’ll work on redirecting the data to “~/Library/Application Support” instead of trying to hang on to portability, which seems like it runs against the Apple grain.

Oh, and thank you @Sam_Rowlands for App Wrapper. It’s been tremendously helpful.

1 Like

I hate generalisations like that.

If it is just demo data then you should have it in resources or copy it to the ApplicationSupport folder. No effect on portability.

If it is user data then you should certainly NOT save it inside the application. Otherwise you “give” the app to someone and suddenly they have all YOUR data. You should also NOT save it in the Application folder. Users often exclude the Application folder from backups or store their data separate from the apps (eg a smaller SSD for apps, a large hard disk or network storage for data).

So where is “portability” impeded?

1 Like

Sorry, I wasn’t trying to generalize. To give more perspective: this app is a Mac OS port of a Windows app which is “portable” in the sense that it is a standalone EXE that does not store data or settings anywhere but in its own folder. The EXE looks for a data folder next to it and reads/writes strictly to this folder. In this way, the app is self-contained and may be run from anywhere…a folder on the desktop, a USB stick, a network share, whatever.

My point was that the mere existence of the “App Translocation” behaviour breaks this kind of portability Or maybe I’m misunderstanding? I’m certainly no expert!

I am glad to hear that you find it helpful, can’t wait to show you everything that I’ve been working on for the last month.

Assuming something cheesy doesnt break things…:wink:

1 Like

I guess next year, they’ll call it “Pepper”.