On May 22, 2013, at 1:45 PM, Christopher Nebel wrote: On May 22, 2013, at 5:10 AM, Shane Stanley < email@hidden> wrote: On 22/05/2013, at 10:06 PM, Alex Zavatone <email@hidden> wrote:
So, that means that you can't tell an app anything because of Sandboxing, right?
Wrong. It means a sand-boxed app can't send Apple events to another app.
And even that's overstating things -- a sandboxed app can't send Apple events to another app *if it doesn't have entitlements to do so*. The default sandbox doesn't allow sending Apple events to any other app, true, but the default sandbox doesn't allow using the network either, and you don't hear anyone complaining that Apple is deprecating the Internet. Basically, for 99.9% of apps, this just isn't an issue -- there are mechanisms to let them do what they need. For the 0.1% that do have issues with sandboxing (as currently implemented), it means they can't be in the Mac App Store, but not that they're out of business. And by the way, this was all covered at WWDC 2012, so refer this benighted developer to the "Secure Automation Techniques in OS X" session. --Chris Nebel AppleScript Engineering
So, yeah, I was being sarcastic in my original reply, but this sandboxing is just onerous and places annoying and expensive implications on the developers.
Let's take this Fortune 20 business case, for example.
For those in the U.S. who know Verizon and know FiOS TV, I was hired to prototype it. Really.
While we were working on the prototypes we noticed that the Design/UI/UX team didn't "speak developer" so I came up with an idea and coded it, first in AppleScript and then in ASOC as a compiled and protected Xcode app that was serialized to run on a specific subset of machines.
What it did was take original content screens in Illustrator CS4 and CS5, export all the graphic layers to PS files, open in PS4, spit out all the trimmed components to PNG, process the coordinate offsets and then export 10 different files that contained the draw code/component data in 10 different programming languages/data structures. The images were then fed to ImageOptim for repeat optimization. The results were then checked into SVN for easy access by the developers.
So, I came up with the whole thing myself, coded the whole thing myself, learned what I needed in Objective C and made an app out of it. I saved the files where I wanted to (in designated folders in the root or the user's root). AppleScript talked to the Finder, TextEdit, Adobe Illustrator CS4/5, Adobe Photoshop CS5, ImageOptim, SystemEvents, the SVN client app called Versions, probably other apps too.
It took what was a 3+ hour per designer process and turned it all into a several minute automated job.
As of the FiOS 1.7 GUI, every screen in the FiOS TV IMG/IPG went through this production tool.
Here's my YouTube page in the FiOS Media Manager on Engadget as evidence (awesome content graphics by Brian.) That screen came straight off of a television set top box running Verizon FiOS:
We went from delivering FiOS TV on 1 platform, to delivering on 5, all while enduring a 30% headcount cut. The net net of this all is a several hundred thousand dollar/million dollar win because of how quickly this tool allowed us to move FiOS TV onto other platforms. All because of the FREEDOM TO USE THE OS that AppleScript offered me by not forcing me to worry about having proper "permissions" or "exceptions" or "entitlements" to simply WRITE A DAMN FILE TO THE DISK WHERE I WANT TO and to be able to simply TALK TO ANOTHER APPLICATION.
Look, when you're the developer on your own box and you are THE admin, and you're trying to push a multi million dollar product on multiple platforms you DO NOT WANT to have to worry about any of this sandboxing garbage.
PERIOD.
This "every app is an island" approach is pure garbage and it places unfair restrictions on developers and quite simply wastes our time.
If someone wants to write malware, I can instantly see people using the address book or the "approved" folders or even images as data structures to save cookies or data that can be be harvested between apps in. Hell, back when we wrote Shockwave, (Director, not Flash) that's the first thing I did - just to see if it could be done.
Evidence:
By locking programmers out of non sensitive areas of the HD unless they go through some extra hoops, Apple is not being more secure, they simply are being more annoying, making their OS less user friendly and wasting more valuable developer time.
Apple's Sandboxing reminds me of Homer Simpson's attempt to bubble wrap everything in his house that might have a sharp edge so Maggie doesn't hurt herself. In the end, the result us that it creates more problems that it solves and creates an unusable house where you're always getting stuck on the bubble wrap.
It's idiotic decisions like this (and I choose my words carefully) why I still live in Snow Leopard and only run Mountain Lion in VMware and then, only when I have to.
There are serious usability, UI/UX and performance issues that have entered the Mac OS since Lion and Mountain Lion and as a Mac user and advocate since 1985, I hate the direction Apple's going with the Mac OS. (iTunes anyone?) Apple is my professional career and I'll be damned sad if it's Apple that makes me leave the Apple platform, but indicators like Sandboxing, the bubble wrapping of the OS and the iOS-ification of the Mac certainly are making me consider when I'll be doing exactly that.
Cheers.
|