Xcode/macOS Observations

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 :slight_smile:

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

	<key>com.apple.security.app-sandbox</key>
	<false/>

This is in .entitlements (which is in pList format)

Does anyone know if AppSupport is the only folder that can be written/read without the users express permission?

Also… it seems “sandbox” creates a ton of disk overhead for each app, by creating a whole folder structure the duplicates in a lot of respects the normal system.

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.

3 Likes

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… :upside_down_face:

Xojo was also supposed to be in the store at one time too and now I dont think it would be possible.

2 Likes

It’s not the only one, but one of the few.

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.

AKA Apple - do what we SAY not what we DO

I think there are other impediments but thats as much as I can say :slight_smile:
The 30% is probably enough of a deterrent by itself

1 Like

What do you mean by a “document based application”? Xcode only offers 3 choices… APP, GAME or CommandLine tool… Of course I am using the APP template.

Perhaps I misunderstand what you are meaning? example perhaps?

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 I see that… but at this point I can’t see how to integrate it into my project (which is already 10k lines of code. so I’m NOT starting over :slight_smile:

That template really exposes next to nothing… a whole 31 lines of code , with next to useless comments

Basiclly the user will save a file (which will be an SQLite Database in reality). And I simply wish to add that to a list the can be saved , and selected as a shortcut later.

There is no document to “display”, as the contents of the database drive various objects and attributes across the application.

Again macOS documentation really SUCKS

I cannot argue this one
MSDN is way more informative

1 Like

and I guess to further complicate things… :slight_smile:
I am using NSWindows (there are no ViewControllers)
and I am NOT using Interface builder… so there are no storyboards

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.