Earlier quoted context omitted.
This works for some type of software, but not all type of software. For example a file server or a file manager wont work. A VCS client wont work. A game engine that needs to keep track of imported resources (especially when you want automatic imports when the file is saved via a 3rd party tool - e.g. saving a model on Blender or a texture on Krita causes an automatic reimport/convert to the engine's format). Basical…
It is possible to still make all of these work by having frameworks that hold the permission to access the functionality, or by having entitlements to more tightly restrict which applications have access to a feature. For example, some backgrounding modes on iOS require an app to get an entitlement to act as a VOIP client, or a mapping directions app. The system access is limited to only give access to the things whi…
I agree with this, but I can't fully get on board with it.
I've worried about the lax security model of desktop software too. Apps these days need to ask permission before accessing my documents, or my desktop, or my downloads folder, but they can still access all my company's code and SSH private keys. It feels wrong for this to be open-by-default. Same with accessing the clipboard, or drawing on the screen, or changing system settings, or injecting code into the Finder: these all seem like things I want to opt in to doing.
But my problem with this — and it's a stretch, I know — is that if the only extra entitlements a program can have are the ones that Apple explicitly allows, then no developer can have any ideas outside of what's already been thought up. As we increase security, we also dry up the innovation well.
For example, there's a Finder API that allows you to add badges to files in a directory to reflect their syncing status. This is an API that Apple allows apps to use — but it was originally implemented by Dropbox, which injected code into the Finder. They had the idea, and the idea turned into a general API.[1] (Now that I think about it, there's almost certainly prior art to this, but Dropbox was where I first saw it)
Similarly, I use a whole bunch of background utilities that currently use the "Screen Recording" or "Accessibility" Privacy permission on macOS, even if they aren't screen recorders or accessibility helpers: things like letting me move windows by holding Option, or switching apps by using the keyboard, or a Spotlight replacement, or adding a delay to ⌘Q, or the snippet manager I just used to insert the '⌘' character there. The entitlements that allow these applications to continue existing were developed after the applications themselves, and to use them, I have to opt-in to functionality that was previously allowed. If the entitlements didn't exist, we'd have to rely on Apple to think it up, and the way they're behaving, I doubt they'd be as generous as allowing one like "can read any pixel and draw anywhere on the screen".
Clipboard managers are another thing that wouldn't exist if OSes started out locked down. Not only do you need to access the keyboard, you need to do so from the background! It was the openness of desktop OSes that gave developers this idea — on iOS, nobody would have thought it up.
Way back when, in iOS 4, Apple gave apps the ability to run in the background, but only certain types of app — music playing, voice calling, and location-based apps received dedicated APIs to do that. Again, Apple waited to see which types of program were popular on other platforms, and based their APIs around allowing those specific kinds of app. If all platforms started life locked-down, maybe one or two of these categories won't be available today.
f.lux, the program that runs in the background and dims your screen red in the evening, is another example. I used to love using it on my desktop computer. But in iOS, they asked for the API, and weren't given it. And honestly, I'm kind of on Apple's side with this one: tinting the screen is the sort of system property I want only done by the OS itself, not an app, so now I use Apple's implementation of the same idea, Night Shift. But again, if the ability to tint your screen did not exist on desktop OSes, I'm willing to bet that Apple would not have come up with the idea.
And even if the idea is there for an entitlement to exist, that doesn't mean that Apple are going to allow it: adding one costs developer time, testing time, and documentation time. In a recent episode of Accidental Tech Podcast, I discovered that Switchglass (a Dock replacement I use) isn't allowed to Quit other apps, a feature I've sorely missed, because it's disallowed by the macOS sandbox. The idea for the entitlement is there, and the need is there, but Apple isn't bothered about apps opting in to such fine-grained functionality as quitting others. Ask me it through a prompt! That would be great!
I hope you see what I'm trying to say here. It used to be the case that macOS "allowed" iOS to exist, because it soaked up all the complexity — and slowly, features that proved popular on the desktop were allowed to exist, in a secure fashion, on mobile. I'm worried about how when I run random programs on my Mac, they have access to all my important files. But I'm also worried about the future. The tighter the grip OS manufacturers have on what sort of code can run on users' machines, the less innovation we'll see, and the worse computers will become.
[1]: https://developer.apple.com/library/archive/documentation/Ge...