For those who don’t know, Sandboxing is a new facility introduced in Mac OS X Lion, which requires applications to list what abilities they want from the system, and then restricts them at runtime so that they can’t do other things. At the moment sandboxing is optional, but fairly soon it’s going to be obligatory for applications that are sold through the Mac Application Store (MAS).
I have a utility application (Neu), currently on sale in the MAS, which is going to run into major problems with sandboxing as it currently stands.
The utility allows the user to create files quickly from templates. Really it just does a glorified copy of a stationery file into a location of the user’s choosing - but it presents the user with a simplified interface for doing this.
The problem with sandboxing comes with how the utility chooses where to create the new file.
Initially Neu was written to be triggered by a Services menu selected from the Finder. It would then create the new file in the location represented by the Finder window that the user had open when they opened the services menu.
I am concerned that this may not work under sandboxing - unless the sandbox system automatically adds any paths that it supplies to an application to the list of allowed accesses.
However, there is a more serious problem. The Finder/Services integration isn’t brilliant, and in particular, there’s no way to right-click on a Finder window and have it show a services menu for the folder that the window represents (see rdar:7719410).
Because of this, I’ve added some other mechanisms for triggering Neu. These mechanisms rely on looking at the front window of the Finder, and inferring the location that the user wants to create files in from it.
I’m assuming that this isn’t going to work with sandboxing. Instead I’m going to have to throw up a “Save As” dialog and ask the user where to save the new file. This is already an option in Neu, but requiring it is going to annoy the users that turn it off by default.
It seems like sandboxing is a great idea, but if we’re not careful it is going to destroy a whole class of utilities which work by integrating with other applications. The Finder is the most obvious of these other applications, but I’m sure that there are many additional examples - for example utilities that watch what track is being played in iTunes, and then do something with it.
Because of this, I think we need the possibility of specifying an entitlement allowing the application to interact with another process id - in a way that then allows the application to do the sorts of things that I’ve described.
In the case of Neu, right now I’d have to request permission to interact with the Finder. However, in future versions I was also planning to allow Neu to infer a save location from the currently open document in the front application - thus letting it integrate more intelligently with whatever program the user is currently using. This would require yet-more flexible permissions.
I have some ideas for a different UI which will get round some of these problems for Neu, but these changes will only work at the expense of some of the intelligence that I had hoped to build into it. Essentially they will force the user to explicitly determine save locations at all times. This is a shame - there are times when we want the computer to make intelligent default choices for us. It seems like Sandboxing may curtail our ability to implement those default choices.