2012 • furbo.org • Page 3

The recent release of xScope 3.0 is our first product to use the new application sandbox that will soon become a requirement for submission to the Mac App Store. I’d like to share some experiences and advice on how to use it in your own products.

First off, Ivan Krstić and the rest of the team at Apple have done a great job in making the whole process easy to implement. Adding entitlements and signing your code will be the least of your worries as you transition to the new sandbox.

Of course there are some applications that have a harder time than others: primarily if those apps require access to all or part of the filesystem (think about syncing data with Transmit, for example.) Apps that make use of AppleScript for inter-app communication will also have a difficult time: this includes our Take Five app. Apple is actively listening to developers who are encountering these types of issues, so if you haven’t filed a Radar yet, quit bitching.

Speaking of Radar, we encountered a fairly nasty problem after launching xScope. Many of our customers are designers and developers who love SSDs. It’s common to use a symlink in your Home folder to put big datasets like Pictures, Music and Movies on a separate hard drive. When you do this, folder access in the application sandbox container breaks. A small number of users who use symlinks are also getting crashes after launching the app that was downloaded from the Mac App Store:

xpchelper reply message validation: sandbox creation failed: 1002
Container object initialization failed: The file couldn’t be opened.

We also encountered a problem when using Sparkle to update an app running in a sandbox: an app can’t update its own binary. Changing Sparkle so that it uses an XPC service is a major architectural change, so we decided to remove the sandbox for the version we distribute on the website.

Besides being the path of least resistance, it also gives us a version of xScope that doesn’t run into the sandbox bugs reported above. I highly recommend that you give yourself this option for any customers that experience sandbox related problems.

All things considered, adding an application sandbox has been a fairly smooth transition. But it’s also clear that we’ve only just begun putting the genie back in the bottle.

Updated January 27th, 2012: The bug reported above is a duplicate of Radar 9865143.

A lot of people I know and respect have been commenting on problems associated with the iPhone mute switch:

John Gruber – On the Behavior of the iPhone Mute Switch
Andy Ihnatko – Unmuting on The Mute Question
Marco Arment – Designing “Mute”
Guy English – Mute This

Both sides of the argument have valid points-of-view. This really is a situation with no right answer given the current mechanisms.

That got me thinking that there might be something missing that’s causing this ambiguity. I’ve come to the realization that this is a problem bigger than just alarms going off at inopportune moments. What we really want is for the devices in our pocket to behave differently depending on where they’re physically located.

Let’s imagine a new feature in iOS called “Homebase”. A user would be presented with a simple UI that lets them select a location that’s a “safe” environment. After the setup is complete, your Homebase would be recognized by GPS coordinates and/or available Wi-Fi networks. The important thing here is that the user gets to define where they feel safe with their device.

With that information developers can make smarter decisions:

Alarms that go off while the mute switch is on make noise at Homebase and just vibrate elsewhere. There’s no need to worry about alarms going off in public places (such as concert halls) and you won’t oversleep when you go to bed with a mute switch on.
The lock screen doesn’t need to display a Passcode lock at Homebase. People who use the Remote app with their Apple TV will no longer be annoyed by an unnecessary security precaution, nor will folks forget to turn their Passcode lock back on when they leave for the local bar (where they’re certain to get a Poopin’ tweet.)
Apps, like Find My Friends, could use cached Apple ID credentials at Homebase and avoid asking the user for them over and over and over and over again.

Of course, this feature is needed most by people who don’t even know the Settings app exists. It’s my opinion that if developers are careful with this additional knowledge about the user and device, default behavior can be adjusted appropriately without additional confusion. It’s analogous to the Energy Saver on the Mac: people don’t question why the screen dims when the power cord is removed because it just “makes sense”.

The examples above use Apple’s own apps, but the Homebase status would be useful for third-party developers, too.

If you’d like to see something like Homebase in iOS, please be sure to file a duplicate Radar.

Year: 2012

Sandboxing

Homebase