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 Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to