What improvements to the developer experience for the Mac sandbox do you think are needed? If you get access all files through an open dialog, you're almost automatically set (and with a few lines of code you can even maintain access to those files). If you do something more complicated, you can write specific sandbox exceptions (as long as you don't want to distribute on the App Store). Privilege separation is also very easy to implement via XPC (complete with automatic proxy objects).
I think most apps don't sandbox not because it's especially hard, but just because it never occurs to the developers.
As noted in another comment, the macOS app sandbox is buggy and unnecessarily rigid in its permissions/capabilities. For many classes of apps, sandbox use is highly impractical or even impossible.
If these issues were fixed I believe that sandboxing would quickly become the norm. Many of us want to use the sandbox but don't want to waste too much effort fighting it.
> For many classes of apps, sandbox use is highly impractical or even impossible.
Worst case, you can see exactly what is being blocked in Console and then add word-for-word exceptions via the com.apple.security.temporary-exception.sbpl entitlement. You can also switch to an allow by default model by using sandbox_init manually.
Even if the sandbox doesn't work for your entire app, you can use XPC to isolate more privileged components in either direction (i.e. your service can be more or less privileged than your main app). What specific abilities are not provided that you think would help?
I don't think that this is correct. There are a lot of things that sandboxed apps can't do, even with exceptions. One such example is opening unix sockets -- a sandboxed app can only open sockets inside it's sandbox. This alone rules out a large class of apps. Shared memory is another problem. (These two currently prevent me from shipping Postgres.app on the Mac App Store)
Using sandbox_init manually sounds like it should be possible in theory, but it is way too complicated in practice. There is barely any documentation on it, and you'd need to be familiar with macOS at a very low level to effectively use it -- which is highly unlikely for application software developers.
Most of the rule types are documented here[1]. Even for the ones that aren't, the error message in the logs uses the same syntax (e.g. if a unix socket is blocked you'll get a complaint about "network-outbound"). You mostly just need to be able to copy and paste.
Isolation via XPC is a good idea, but it's also a good chunk of overhead. It's a lot of added effort and room for error in the case of one-man indie apps/side projects (which a lot of mac apps are) for barely visible benefit and it's potentially problematic for scenarios requiring high rates of throughput.
For examples where (at least to my knowledge) the macOS sandbox isn't flexible enough, consider trying to write a reasonably capable file manager or terminal that works within the sandbox's bounds. Or even a simple music player capable of opening playlist files which could point to music files sitting anywhere – not just the user's home directory or the boot volume but anywhere on the local file system.
I think most apps don't sandbox not because it's especially hard, but just because it never occurs to the developers.