Resources folder on mac, and the good old days

[Mark Waddingham]

On 2021-03-29 03:13, Neville Smythe via use-livecode wrote:
>> you may already know this, but this will not work in a standalone!
>> We will surely not have write permissions in that folder!
>> 
>> As a workaround I would probably use -> specialfolderpath("temporary")
>> Or even write the text to -> the tempname

> There is no problem writing to the resources folder. That’s the
> logical place to put the user-changeable stack files for a standalone,
> making the auxiliary files invisible to external fiddling by the user,
>  which a Good Thing (although that does make the app look different on
> Windows or Linux).

Unfortunately this has never been true on macOS X.

The Resources folder (which is in the macOS app bundle) should be 
treated as read-only...

This has always been true - the correct (Apple guideline compliant!) 
place to put files that are 'internal' to the app but created/modified 
at runtime and which should persist between restarts of the app is in 
the 'Application Support' folder - in a sub-folder which is named the 
same as the app's id (e.g. com.myapp.mycompany).

[ Apple guidance is here - 
<https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html> 
]

The read-only ness of resources isn't strictly enforced - especially if 
the standalone is built on the machine it is run (app bundles downloaded 
from the internet, for example, have file attributes added which mark 
them as 'quarantined' - even if unpacked from a zip/archive)... However, 
you will notice some more 'unpleasant' effects, typically, if you move 
the standalone to another machine - these will range from prompt dialogs 
allowing access, to dialogs requesting root permission (if the user has 
put the standalone, say, in /Applications).

In contrast, I do not believe that writing to stuff under 'Application 
Support' ever produces a user-visible prompt dialog on any version of 
macOS.

Additionally, code-signing requirements are becoming more stringent over 
time - off the top of my head I can't remember whether codesign has 
started including non-executable resources in the signature - but as 
soon as it does (if it doesn't already), any signed and notarized app 
will break if any of the files in the app bundle are modified / removed 
/ added to.

> As for the Good Old Days of free distribution to other Mac (desktop)
> users, they haven’t gone. Apple is making it harder for the
> uninitiated to find out how to open “unsafe” files, but they don't
> keep it a secret. And while recent rumours abound  about unnotarized
> apps not working at all on some future MacOS, it does seem unlikely
> that will actually happen, and if they do that’s time for us all to
> reboot to Linux.

Indeed, it is unlikely that Apple will ever completely stop unnotarized 
apps from running (although they keep changing what you have to toggle 
to enable right-click Open to open the app!) - but ensuring you use 
appropriate paths for temporary / private writable app files means the 
least friction for the user.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps