As many of you know, I have decided to venture into writing desktop applications for macOS using nothing but Swift. And so far things have gone pretty well… aside from places where I assumed macOS would be similar to iOS in syntax, and they were worlds apart, but pleased when complex things I had written for iOS could be converted to macOS, just by changing UIxxx to NSxxx
But one thing I discovered today, which took me an hour or more to figure out, was the fact that by default a Swift/Xcode project for macOS, activates the SandBox with READ ONLY permissions for files.
My current app during startup, looks for and creates if necessary two SQLite databases, one in ApplicationSupport and the other (for now) on the users desktop.
The first database was created with no issues… but the desktop one kept bombing with an SQLITE_CANTOPEN error. If I pointed it to AppSupp it worked.
So I turned OFF Sandbox
Pro tip, you’ll find that once you get to notarizing your app, setting this to “false” will fail obscurely. As I learned by wasting a DTS ticket, only removing the entitlement from the .plist is valid; setting it to “false” is not.
Thanks for that… I had planned on at some point perhaps putting this app into the Apple Store… but from what I see, sandboxing is just too restrictive. Too many apps “need” to create files that the user really doesn’t need to care about, but are required for normal operation. Heck its near impossible to even keep a “Most Recent Used File” list without jumping thru hoops to create security scoped bookmarks… which so far comprehenive documentation with examples is near impossible to find
I hear you, yeah. I’d love top have Fire in the app store, but it’s just not isn the cards for us to run without sandbox. It was major trouble to just get things working when notarized and using the new Hardened Runtime.
Can’t wait to see what 10.16 will break, in two weeks…
Correct, not only that but each file transaction also goes through several processes before reaching the actual disk, and is slower (marginally, but still). It’s also wonderful when one of the daemons crashes or stops responding, meaning your app can’t write any files, not because you f’ed up, but because Apple don’t care enough to fix their bugs.
Interesting, I have seen people who’re able to Notarize with the entitlement set to false. It surprised me that this was allowed. I personally wouldn’t recommend it, and would do what you suggest in removing the actual key/ Maybe it’s like the App Store, whereby favored developers are allowed to do what they want, where as the rest of us have to suffer the rules.
If you want a recent items list, create a document based application and utilize NSDocument. DO NOT use Security-Scoped Bodgemarks for a Recent Items list. It runs the potential of corrupting the Sandbox container. If you don’t want to use a document based template in Xcode (or you use Xojo), the code to utilize the correct functions is included as part of my old Sandbox Kit or as part of my upcoming App Kit.
Judging by the reports coming out, I’d say everything! lol!
I don’t think it will ever happen, Apple will take their 30% cut and make it so that when people search for Xojo, It’s way down the list.
There used to be multiple app templates, in fact there used to be a lot more “useful” templates.
When you create a new “App”, select “Create Document-Based Application”, I am assuming this is close to the older “Document Based Application” template, you used to get a lot of standard functionality for FREE with the old template.
Yeah, it’s not about the code. I scrutinized it many years ago when first trying to Sandbox applications and struggling. It’s about the “Magic” that happens behind the scenes when you use the “right” objects. For which there was/is no public documentation that I could find at the time.