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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
