Published: 01/11/2011 | Last Revision: 15/12/2011

The email that just landed in my inbox made me perk up and take notice. From Apple Developer with a title of ‘Sandboxing and the Mac App Store’, the email goes on to say: “Sandboxing your app is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users’ systems. As of 1 March 2012 all apps submitted to the Mac App Store must implement sandboxing. Enabling the default sandbox environment is as simple as checking the Enable Entitlements checkbox in Xcode target settings, allowing you to begin sandboxing your app. If your app requires access to sandboxed system resources you will need to include justification for using those entitlements as part of the submission to the Mac App Store. Apps that are being re-engineered to be sandbox compatible may request additional temporary entitlements. These entitlements are granted on a short-term basis and will be phased out over time.” This could not be clearer. As of 1 March 2012, any app sold through the Mac App Store must use sandboxing to protect itself and other code on the computer. Frankly, this is fantastic news for users. Apple’s Mac Store has followed on from the huge success of the iOS AppStore by allowing for extremely simple application purchase, download and installation. It is normally just a one-click operation, and really couldn’t be simpler. Not only does this work well for small utilities as well as larger apps, it has worked just fine for the huge upgrade from 10.6 Snow Leopard to 10.7 Lion OS versions too.

For a user, it is a win-win. Simplicity of purchase and install, and then a one-stop shop for upgrades too. Better still, almost every app in the AppStore allows you to install onto multiple machines provided they are owned by you and logged in with the same user account. Any developer will understand just how much this has changed the landscape for application development on that platform. Now one key differentiator for the iOS AppStore was that it only allowed full walled-garden digitally signed applications from the beginning, with no exceptions. The Apple desktop operating system, OSX, is different. Just as with Windows, you can build your app and sell it with no digital certification required. With the recent arrival of the Mac OSX AppStore, it still allowed for applications which did not follow the sandboxing rules. But that changes shortly. The deadline from Apple is interesting – it was originally going to be November 2011, so it has been delayed. Doubtless this was a pragmatic decision based upon the uptake from the community. What will the sandboxing limit? Well, you can kiss goodbye to inter-application scripting and interactions, and you won’t get system-wide file system access either. In a Windows context, this might mark the final death throes of OLE Automation. It will be interesting to see how Apple will handle the Automator scenario. The question to be asked is this: how brave will Microsoft be with the Windows 8 platform? The 64-bit version of Windows 7 does not allow for the installation of unsigned drivers by default, but this does not extend to sandboxed and digitally signed applications. Rumours are circulating that Microsoft will be considerably more robust about this on Windows 8, especially on the ARM platform. With the ARM platform, there is no prior history of existing applications, of course, so the entire platform is starting from a blank sheet of paper. This makes it much easier to require and enforce tougher requirements for developers. Whether Microsoft will allow the same, or allow for a user-settable value of ‘only run sandboxed and digitally signed applications’, is something we will have to wait to see. Personally, I would happily enable such a setting on all of my day-to-day computers without hesitation. It would make them far more robust against malware attacks and all the other nasties which seem to consume much of our time on our computers at home and at work. Even if Microsoft is its usual hand-wringingly slow and apologetically tardy self over such a matter, the writing is now clearly on the wall. The movement is simply inevitable. Application writers need to start thinking long and hard about how their applications will run in a new world order where operating systems will lock down applications in a much tougher walled-garden regime. It will not be enough to ensure that the code is clean enough to cross-compile onto ARM: we should expect a whole host of extra requirements for security, sandboxing and so forth. And also, quite likely, an inevitable shift in licensing away from the one-user/machine one-license world we have had for many years. Maybe we will get one user account, multiple machines as in the iOS and OSX AppStores. Or maybe it is time to look at innovative pricing and runtimes. For example, last night I had dinner with a group of senior developers from a well-known high-end systems management tools company. We talked at length about new ways to license their product, and I came up with the “give me access for an hour” model. This would allow for on-the-fly licensing for a restricted time period to use their tool. After which, it would simply stop working until “more money is put in the meter.” For a tool that you might use only occasionally, maybe once every few months, this sort of innovative licensing becomes interesting. My fellow diners are going away to think about ways of implementation such a scheme, and what the functional value is of their tool on a per-hour runtime usage model, rather than a convention “buy N seats covering M IP addresses, plus an extra 20 per cent for a support contract”. Pay for play is really just around the corner for even mainstream applications, and I am not sure enough developers are thinking in a truly innovative way about where their future revenue streams will come from.

Is Microsoft listening?

Microsoft is running a major blog all about the Windows 8 development process at http://blogs.msdn.com/b/b8/ and it is getting a flood of responses from developers and other interested parties. Even better, they seem to be listening to the feedback and, to my surprise, acting on it. Why am I surprised? Well, Microsoft has traditionally been really rather inward looking when it comes to the development process. I know it routinely trots out the line that it listens to its customers, prioritises key features and so forth. But the reality is that much of that is simply validating what it was going to do anyway.

Looks like Microsoft might actually be listening to what its users want of Windows 8.

Nevertheless, it is somewhat fascinating to see how they are modifying and changing the user experience, especially for the Metro part of the desktop. It might be pertinent to ask that this is happening really rather late in the day. If Microsoft is aiming to deliver a feature-complete Beta in January, followed by something around April, with completion fairly soon after that, then the clock is ticking at a quite furious rate. That said, I would far rather Microsoft use every second up till its internal lock-down deadlines to make improvements rather than stick its head in the sand and pretend its customers don’t exist. A number of other well-known software companies could benefit from taking such a pro-actively open development process, even if some of it is inevitably marketing spin.