I have been battling some weird bugs in my app that only show when it is downloaded from the Internet. The downloaded version gives exception errors whereas the local version is fine. However, diff -r shows the files to be identical. I think I have traced it to OS X placing restrictions on a downloaded app that is not code signed. The one I have identified so far is the app cannot access the files in its containing folder. This is under both Sierra and High Sierra.
Does anyone know what restrictions are placed?
This is a freeware app and I have not wanted to go the trouble and expense of code signing. Previously if the user opened the app despite warning it ran without problems but I tested some earlier versions that have been running without problems for over 10 years and they now have same problem.
That’s not a safe option for macOS. You really should use ~/Library/Application Support/My App/ for user files that are associated with teh app, but not documents or saved files (which should go into ~/Documents/).
Thanks Greg and Tim the quarantine section is horrifying!
Some parts of my app are script-driven by scripts that a user may modify to customize the behaviour. Users need to be able to access them so tucking them away would not be helpful. Having them in same folder as app has always been easily understandable.
Sounds like I need an installer similar to Inno Setup that can put install files in both App and Doc folders but I don’t know of one. Is there something equvalent to Inno for OS X?
Quarantine is no issue when your apps are code signed.
But wait until you get in touch with macOS 10.14 … now that’s terrifying. The new protections can mess up your app really bad. It will definitely needs some changes in your code.
macOS 10.14 will be available to the public on Monday 24 September … that’s about 6 days from now. Scared already?
That’s not an issue since a user has full access to their ~/Library/Application Support/ folder hierarchy. Plus, if you update your app, you don’t muck up the users’ script changes since you only change the app portion.
on another note… wonder how many 10’s of thousands of people are going to be SO P*SSED off, when they install Mojave, and 1/2 of all their programs just stop working. The average consumer doesn’t know 64bit from a hole in the ground. My sisters are both somewhat tech savvy, and they were amazed at how many (and what) 32bit programs they used on a daily basis, that would come to a screeching halt.
FYI… I don’t plan on moving my main machines to Mojave for quite some time (if ever)
Thanks for all the advice. I found a workaround that is effective for my app. After compilation I move the default script folders into the app package contents (the user is not meant to change these just put override scripts in an automatically crated app support folder in Documents if they wish to use modified scripts).
Gatekeeper’s random path does not affect the app’s access to the scripts because they are part of the package. I hope Mohave does not destroy this workaround.
I do have the 64bit version of my app already working in Xojo so that side of Mohave should not be a problem.
I did start applying for a certificate from Apple to allow code signing. They are meant to be free to university faculty developing freeware. However, I started the application incorrectly and find Apple will not let me cancel it or otherwise get rid of the errors (got rid of cookies and tried a different browser to no avail partial application must be stored on server). Have asked Apple support to remove erroneous application but lloks like that will take a day or so. Not an easy road to travel!
You might find a lot of trouble with these workarounds.
Modifying your own package is considered malicious activity, and you may even get flagged by malware scanners.
Do not do not do not just write to ~/Documents. I’ve mentioned why in the past:
[quote=404430:@Tim Parnell]If your user needs to access the data outside the app, use a SaveAsDialog. If the app doesn’t need to allow the user access the data (like a shoebox app), store it in SpecialFolder.ApplicationData.
Treat the user’s system like you’re walking into the home of someone with OCD.
Just because you don’t care if things are a mess doesn’t mean they share that attitude.[/quote]
If you package your app and use data correctly you will have no problems with sandboxing, translocation, and the future.
In your situation, if your scripts are modifiable and need to be, you can implement a script editor within your app, or an import/export method.
