# Xcode/macOS Observations **URL:** \ **Category:** Other\ **Created:** [8 June 2020 20:11 UTC](https://ifnotnil.com/t/xcode-macos-observations/592 "2020-06-08T20:11:45Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![DaveS](https://ifnotnil.com/user_avatar/ifnotnil.com/daves/32/79_2.png) [@DaveS](https://ifnotnil.com/u/DaveS)\ **Post date:** [8 June 2020 20:11 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/1 "2020-06-08T20:11:45Z")
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 ```auto com.apple.security.app-sandbox ``` 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. ---
**Author:** ![dwarfland](https://ifnotnil.com/user_avatar/ifnotnil.com/dwarfland/32/548_2.png) [@dwarfland](https://ifnotnil.com/u/dwarfland)\ **Post date:** [8 June 2020 20:31 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/2 "2020-06-08T20:31:57Z")
> [@DaveS](#): > > 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 > > ```auto > com.apple.security.app-sandbox > > > ``` > > This is in .entitlements (which is in pList format) 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. ---
**Author:** ![DaveS](https://ifnotnil.com/user_avatar/ifnotnil.com/daves/32/79_2.png) [@DaveS](https://ifnotnil.com/u/DaveS)\ **Post date:** [8 June 2020 20:38 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/3 "2020-06-08T20:38:46Z")
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 ---
**Author:** ![dwarfland](https://ifnotnil.com/user_avatar/ifnotnil.com/dwarfland/32/548_2.png) [@dwarfland](https://ifnotnil.com/u/dwarfland)\ **Post date:** [8 June 2020 20:40 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/4 "2020-06-08T20:40:43Z")
> [@DaveS](#): > > 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. 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… 🙃 ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [8 June 2020 20:51 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/5 "2020-06-08T20:51:24Z")
Xojo was also supposed to be in the store at one time too and now I dont think it would be possible. ---
**Author:** ![samRowlands](https://ifnotnil.com/user_avatar/ifnotnil.com/samrowlands/32/121_2.png) [@samRowlands](https://ifnotnil.com/u/samRowlands)\ **Post date:** [10 June 2020 04:31 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/6 "2020-06-10T04:31:10Z")
> [@DaveS](#): > > Does anyone know if AppSupport is the only folder that can be written/read without the users express permission? It’s not the only one, but one of the few. > [@DaveS](#): > > 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. 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. > [@dwarfland](#): > > 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. 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. > [@DaveS](#): > > 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 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. > [@dwarfland](#): > > Can’t wait to see what 10.16 will break, in two weeks… Judging by the reports coming out, I’d say everything! lol! > [@npalardy](#): > > Xojo was also supposed to be in the store at one time too and now I dont think it would be possible. 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. ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [10 June 2020 04:41 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/7 "2020-06-10T04:41:49Z")
> [@samRowlands](#): > > 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. AKA Apple - do what we SAY not what we DO > [@samRowlands](#): > > 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. I think there are other impediments but thats as much as I can say 🙂 The 30% is probably enough of a deterrent by itself ---
**Author:** ![DaveS](https://ifnotnil.com/user_avatar/ifnotnil.com/daves/32/79_2.png) [@DaveS](https://ifnotnil.com/u/DaveS)\ **Post date:** [10 June 2020 04:58 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/8 "2020-06-10T04:58:39Z")
> [@samRowlands](#): > > 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. 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? ---
**Author:** ![samRowlands](https://ifnotnil.com/user_avatar/ifnotnil.com/samrowlands/32/121_2.png) [@samRowlands](https://ifnotnil.com/u/samRowlands)\ **Post date:** [10 June 2020 05:04 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/9 "2020-06-10T05:04:27Z")
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. ---
**Author:** ![DaveS](https://ifnotnil.com/user_avatar/ifnotnil.com/daves/32/79_2.png) [@DaveS](https://ifnotnil.com/u/DaveS)\ **Post date:** [10 June 2020 05:23 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/10 "2020-06-10T05:23:58Z")
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 🙂 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 ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [10 June 2020 05:32 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/11 "2020-06-10T05:32:13Z")
> [@DaveS](#): > > Again macOS documentation really SUCKS I cannot argue this one MSDN is way more informative ---
**Author:** ![DaveS](https://ifnotnil.com/user_avatar/ifnotnil.com/daves/32/79_2.png) [@DaveS](https://ifnotnil.com/u/DaveS)\ **Post date:** [10 June 2020 05:32 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/12 "2020-06-10T05:32:20Z")
and I guess to further complicate things… 🙂 I am using NSWindows (there are no ViewControllers) and I am NOT using Interface builder… so there are no storyboards ---
**Author:** ![samRowlands](https://ifnotnil.com/user_avatar/ifnotnil.com/samrowlands/32/121_2.png) [@samRowlands](https://ifnotnil.com/u/samRowlands)\ **Post date:** [10 June 2020 06:56 UTC](https://ifnotnil.com/t/xcode-macos-observations/592/13 "2020-06-10T06:56:10Z")
> [@DaveS](#): > > That template really exposes next to nothing… a whole 31 lines of code , with next to useless comments 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.