How does Xcode work to manage its unadorned project folders, anyway? (I mean, I know it offers you that component that elevates and escapes the sandbox and sprays stuff into &#x2F;Developer, but Xcode still <i>works</i> if you decline to install that.)<p>Setting Xcode aside, though, the idiomatic &quot;modern OSX&quot; model seems to be one where GUI apps have to <i>own</i> all the files they interact with, usually clumping them together into media-typed document bundle folders. (Xcode&#x27;s mechanism wouldn&#x27;t be nearly as inexplicable if the rest of the files lived <i>inside</i> the .xcodeproj.)<p>An idiomatic OSX text editor app would thus, naively, probably have to be quite crippled: the GUI app would have to simply copy your repo into a project document, and make all its edits in there. No ability to watch for git-initiated changes to the source dir or anything.<p>But I think there <i>is</i> still a way to idiomatically support the Unix philosophy of &quot;small components, working together against shared files&quot; in modern OSX. You just can&#x27;t rely <i>solely</i> on GUI apps to enable it. Instead, you need a separate CLI component that &quot;lives in&quot; the un-sandboxed Unix world to be the manager of the Unix-style integration.<p>Imagine the text editor working on its project bundle, and then a separate CLI component sitting there and just monitoring both the project bundle, and the git working directory—and bidirectionally syncing between them. The sandboxed app still gets to be a sandboxed app, and &quot;works&quot; on its own when the component isn&#x27;t installed. The component—brought in from outside the MAS, maybe through e.g. Homebrew—just makes extra magic happen.<p>I&#x27;m unsure why more MAS apps aren&#x27;t designed like this, honestly. It&#x27;s perfectly sensible for Development apps, at the very least; we all install Homebrew anyway.