LiveCode Forums.

Hi all,
I'm hoping someone has some insight on this weird issue: i'm near release of an app for a limited audience - mainly PC but some Mac users. The app builds for PC and Mac just fine but is obviously not codesigned etc.

The newer version so macOS make it near impossible to run a downloaded, unsigned app, insisting the 'app is damaged' and wanting to bin it. So i ventured into codesigning/notarising/stapling process on Mac using the corresponding lesson https://lessons.livecode.com/m/4071/l/1 ... code-stack

Doing this manually exceeded my attention span by about a few hours, so i opted to use the stack mrSignNotarizeHelperV3.livecode from this same lesson, which promises to do this automatically and to my surprise it really does.
I get a message from Apple that the app is codesigned/notarised/staped and all should be good. The app can be downloaded and run without MacOS throwing a fit and wanting to bin it.


Now the problem is that this process seems to change the contents of a file added in the 'copy files' section the standalone build settings.
In particular, this is the config file which is a key for decrypting libraries used to access LiveCloud - and because contents change i can no longer decrypt the libraries for liveCode and have a nicely stapled but dead app.

I did double check by building several times by rebuilding and keeping copies of each build which weren't touched while and I codesigned/notarised/stapled the others - every time the same problem: Unsigned apps can use LiveCloud without a problem (the config file is unchanged) while codesigned/notatised/stapled apps seem to change the contents of the config file, giving me nicely stapled but dead apps...

This file resides in the following location in the app bundle: <app>/Contents/Resources/_MacOS/CanelaDB/config/config
The idea is that on first run, this folder is copied to the user's Documents folder along with the 'mainstack' as this is writeable location. This works absolutely fine on Mac and Windows with unsigned apps. But seemingly not with stapled apps and that is because the contes of said config file change.

Can anyone offer any insight into how this is happening and why??
many thanks
Stam

If you compare the two versions of the config file, can you spot any differences? If there is something you can change in the copied file, that might fix it. Otherwise this sounds like something you should ask Mark Talluto about.

I love Matthias' notarization tool. He made it so easy.

Thanks Jacque - was just posting the question here to see if anyone else has had issues with files within the application bundle being altered by the notarization/stapling process, or if it is likely to be a different issue. FWIW, doing the process manually leads to the same result so it’s clear it’s not Matthias’ stack doing this. And it’s a great stack!


I had already asked on LiveCloud Forums. Seems to not be a known problem - the advice I’ve received so far is to not use the users Documents folder as a writeable location but instead use the Application Support folder.

Not sure what difference that will make but will heed this and also restructure the app and remove more more of the logic out of the splash stack that is built as the standalone. Hopefully that may avoid this issue…

I can't see how the destination folder would matter as long as it's writable, but if that works let us know.

Well i'm happy to report the issue is resolved.
I moved a lot of logic (some of which called on liveCloud) ut of the the splash stack and into the mainstack the splash stack opens.
I left the destination for the apps main folder in Documents (mainly as for now in need users to easily access this). The notarised/stapled app works a treat now
I guess the key is that if using liveCloud, don't access this directly from the stapled app and works fine from any other stacks called...