Way back in the 80s, right after Apple had introduced the world to the graphical user interface all of the other PC companies scrambled to add windows and mice to their machines. For years when you sat down at an early Windows machine you saw this: you move the mouse and a bit later the pointer on the screen moved. As machines got faster the lag went away, until eventually it was gone.
But the magic thing about the Mac was that they had practically zero latency on lesser hardware from day 1. And when I say practically zero I mean that there was no perception that you were controlling a mouse on your desk. It was a one to one, hand to pointer, as if the pointer was directly connected to your hand. It was magic.
Apple put the human interaction first. The mouse and its movement were built into the hardware and software at the lowest levels. The Apple guys knew that if the mouse seemed to lag behind the user’s actions, even for just a split second, the magic was broken.
Fast forward to today. The Kindle fire reviews are pouring in and it looks like a great little device. Amazon certainly has a clear answer to the iTunes Store/App Store. But in watching the videos its clear that it’s still Android underneath. Scrolling around in the browser looks more like a gesture than a one to one interaction. The user swipes, and a moment later the content moves. Just like those Windows 1 machines, you feel as though you’re interacting with the device, rather than interacting with the content on the screen. There’s no one to one, and no magic.
Lots is being written about Apple’s new sandboxing requirements: Is it secure? Is it the best way? Is it too soon? All good questions. It’s good that someone’s thinking about that stuff. A bit theoretical for my needs, though.
I just need to know the constraints, so I can build the best app possible within them. That sounds easy enough, right?
Sandboxing makes each app work in a safe restricted space. Safe because nothing dangerous is allowed, except what you specifically request that your app will do. And even then only very limited things.
To help ease the transition, many unsafe things are still possible by requesting “temporary entitlements”. This will allow unsafe things to continue working, but as the name suggests, temporary entitlements will end someday, probably someday soon.
The odd thing is that lots of simple stuff that we expect our Macs to do is only possible with temporary entitlements. What happens when these entitlements are removed? Will they be replaced by something else? If so, what?
OK, we’re getting too theoretical again, let’s reel it in a bit.
What does this mean for YourHead Software? We make Stacks, a plugin for RapidWeaver, which will be sandboxed since it’s in the app store. That means we’ll be running in RapidWeaver’s sandbox.
When you drag a giant image into Stacks it would be nice to store a link to the image rather than copying it into the RapidWeaver file. In the past we’ve done this with a path; or better, a file-URL; or better still, a file reference (called a Bookmark File URL in Cocoa). This is a fast and efficient way to connect with things like your iPhoto library without copying 50MB images around the file system. Obviously, this is something we’d love to keep doing.
The problem is that this is only possible with a temporary entitlement that allows read access to all files. Lucky for me RapidWeaver will probably need this entitlement too, so I’m all set — for a bit.
But then what?
At some point the temporary entitlement will go away. The folks in charge of sandboxing know being able to read all files is dangerous. I guess that makes sense. But really, that’s not what Stacks needs to do. Stacks just needs to read files the user specified a while ago, when they last used Stacks. That doesn’t sound very dangerous to me. It seems like that should be allowed, but will it be? No one is saying.
There are hints from some at Apple that this is being working on. But there are other hints that suggest that some things deemed too dangerous simply won’t be possible, and that’ll just be tough luck for the apps that currently do them: cut the feature or get out.
This feature plays a more prominent role in Stacks 2, which is nearing completion. Should I play it safe and cut it out of Stacks 2? Should I risk it, perhaps enraging users when I have to cut it later? Or is there some other way I should be building this so that it’s inline with the Apple’s goals? What are Apple’s goals?
Practically speaking, there are a lot more questions than answers.
Answers to obvious questions: Yes, I’ve submitted radars about this. Yes I’ve talked with Apple engineers directly about this, even in person. Yes, the engineers working on sandboxing. Great guys, but muzzled by NDA, so not as helpful as I’m sure they’d like to be.
Also: Just wanted to say thanks to the RealMacSoftware guys who do build RapidWeaver. We’ve been figuring this out together since June. Those guys are awesome.