It’s funny how the casual meandering of your mind can be a source of inspiration. This morning, my mind casually turned to thinking about all the work that Mac developers need to do to get access to privileged APIs — like location, contacts, or the accessibility APIs. My experience of going through the motions to enable these permissions for the apps I use, along with hearing of the lengths developers go through to make this as seamless as they can, reveals to me the clunkiness that this entails. I could imaging this being a huge source of frustration for these developers, not to mention a huge source of support requests.

It’s laudable of Apple to lock-down access to these APIs: the days of assumed access to everything is over, and I believe we are better for it. But I believe it’s worth considering ways to streamline the process of granting these permissions, making it easier to work with them without any sacrifice to the user’s security or privacy.

I’m wondering if one such approach could be to do something similar to how permissions for web pages are managed. In most browsers, clicking on the pad-lock icon just left of the URL brings up a popup listing all the capabilities the website has access to, such as whether they can use the microphone, whether they can show notifications, etc. Within this popup, the user can grant or revoke these permissions, controlling which APIs the JavaScript on the website can use. The web-site itself cannot do anything with this pane: all that can be done is to provide instructions on how enable these permissions, and progressively enabling or disabling features based on whether those permissions are granted.

Maybe something similar would help for macOS apps. What I had pictured in my head is something similar to the following (no mock-ups, sorry; you’ll need to use your imagination):

  • The app will disclosed in their Info.plist the privileged APIs that they need access to (they might do this already, I’m really not sure).
  • A new “Permissions” menu item will be added by the OS to the application menu. This menu item is beyond the control of the app: it could not be automatically triggered or otherwise controlled.
  • Clicking this menu item will bring up a window listing all the permissions that the app has disclosed. Beside each one is a toggle, allowing the user to turn them on and off at will. Like the menu item, this window is managed by the OS itself, not the application, and could require users to enter their admin passwords before enabling the permissions if necessary.

I can see this approach having some benefits to both users and developers. This will reduce the level of friction involved in dealing with permissions, making it easier for the user to enable, and most importantly disable, these permissions when needed. The app developer has an easier time asking the user to enable these permissions: no need to do things like open the Settings app and draw arrows on screen pointing to the accessibility pane. Since this is all managed by the OS, the various setting panes can still exists, but they become secondary avenues to controlling these permissions. Conceptually, the permissions belong to the app, which maintains the wholistic app paradigm that Apple is moving towards, not to mention eliminating the need for the user to context switch when they open the Settings app.

I’m not a Mac developer so I’m not sure how possible this is. I can’t imagine this approach would break any of the existing APIs of AppKit: this will all be stuff that Apple needs to do. I’d be interested in hearing what others think of this approach, so let me know your thoughts on this.