Sunday, October 2, 2011

The App Culture

Jason Snell:

Not only does this approach risk turning the Mac App Store into a wasteland of arcade games and one-trick-pony apps, it risks dumbing down the Mac app ecosystem as a whole. While developers can always opt out of the Mac App Store, they’re reluctant to do so. Not only are they afraid that Apple will one day make new Macs unable to run apps that don’t come from the App Store, but they realize that if their competitors are in the Mac App Store, they risk losing sales. It’s generally too expensive to develop two separate versions of an app, so the net result of tighter App Store restrictions could be that Mac apps everywhere—on and off the store—will actually become less powerful.

Not widely discussed so far is the huge gulf between the theory of the sandbox and the reality. It would be great to be able to buy a utility like SuperDuper from the Mac App Store, but we all understand why that doesn’t fit Apple’s rules. Yet there is also a large class of applications that are well-behaved and could fit in with the idea of what the sandbox is trying to accomplish, but that fall victim to bugs and limitations of the current sandbox implementation. Apple has in recent history done a good job of dogfooding and providing for gradual transitions. The app sandbox is a notable exception. Not only is it not ready for prime time, but the mechanics of the transition remain a secret. We’re now less than a month from November. Many developers have in good faith tried to adopt sandboxing, filed bugs, and there has been virtually no response.

It’s not even a question of opting out. What happens if an application that’s already in the Mac App Store can’t be sandboxed? People have already bought it, and they expect fixes and updates. Apple changed the rules, but developers will get the fallout.

3 Comments RSS · Twitter

"Apple has in recent history done a good job of dogfooding and providing for gradual transitions"

Ummm...

Perhaps you are referring to iOS. But OS X has had the feel of an EOL'd platform in recent history. (Or perhaps you are using 'recent' to refer to a period no longer recent.)

"The app sandbox is a notable exception. Not only is it not ready for prime time..."

Is Lion ready for prime time? I'd love to think the sharp edges of the sandbox is are an exception, and not the rule. But I'd love a pony too.

"It’s not even a question of opting out. What happens if an application that’s already in the Mac App Store can’t be sandboxed?"

Well, opting out is the answer to that particular question. If you're already in, you apologize, and take the app out of the Mac App Store. The only (rather enormous) problem, from a dev perspective, is whether or not you'll have the opportunity to continue serving the platform while opting out in another year or two.

You pretty much knew you were signing up for a dysfunctional system when you put your stuff in the MAS in the first place, no? I genuinely understand the lure from a dev standpoint, but still, your eyes were open.

"Many developers have in good faith tried to adopt sandboxing, filed bugs, and there has been virtually no response."

A belief in good faith has become incompatible with the platform. A useful and well-implemented multi-app Capture Key doesn't fit the iOS model, so why should OS X support such a workflow. One size fits all. If it make sense on a smart phone or a game console, why the hell wouldn't it make sense on a general purpose computer, right?

(And IMHO, you've linked to the wrong Macworld article on the topic. Ihnatko is the first person I've noticed to make the utterly correct observation that AppleScript is where the canary drops dead in the coal mine.)

I'm worried you're not progressing along the Kübler-Ross steps here, Michael. This movie doesn't end particularly well.

"Apple changed the rules"

Rules written on sand. The bouncer standing behind the velvet rope who doesn't answer questions is the only real rules in these Hobbesian parts...

In such condition, there is no place for industry; because the fruit thereof is uncertain: and consequently no culture of the earth; no navigation, nor use of the commodities that may be imported by sea; no commodious building; no instruments of moving, and removing, such things as require much force; no knowledge of the face of the earth; no account of time; no arts; no letters; no society; and which is worst of all, continual fear, and danger of violent death; and the life of man, solitary, poor, nasty, brutish, and short.

@Chucky Apple built real apps with Carbon, Xcode, Intel, 64-bit, garbage collection, etc. well in advance of requiring developers to do so. Lion and Xcode get special privileges in the Mac App Store, but “normal” apps like iLife seem to follow the (pre-sandbox) rules. Whereas, Preview and TextEdit are the only sandboxed system apps, and there’s no way that Mail or iTunes or Aperture could be sandboxed—let alone something like Xcode.

I’ve seen some problems with Lion, but overall I think it was more ready than previous cats.

I didn’t like the original Mac App Store guidelines, but I never dreamed that Apple would forbid something as basic, say, as double-clicking a file in one app to open it in another app.

I thought Ihnatko’s article deserved its own post. The automation situation is the sort of thing you would expect Apple to have explained at WWDC, but I can find no evidence that they did.

The sandbox discussion in Apple's developer area has not changed and now its a week left to submit before you will need sandboxing. That's the fear, anyway. Realistically, though I don't see it happening.

Not one posting on the sandbox discussion from anyone with authority at Apple. Also a search for any mention of a sandboxing deadline returns nothing other than a slide at WWDC. There has been no email sent to me as a developer explaining this change. There is no mention of November at all by Apple employees other than those who post on sandboxing group, and I think that they are in the same place as us - in the dark. Doing a search on Google or while logged into Apple developer area returns nothing.

I think that with the right relaxations, it may work for lots of apps. For instance a Finder replacement type app may need to read the entire hard drive, but it may not need to write much. It certainly will not need to access the internet.

Also I have no issue with someone running my app for the first time (and maybe once in a while later) being presented with a security dialog to the effect of "This signed app is requesting access to everything on your computer - Allow?"

It increases security the more applications are delivered through the app store. Whatever that takes. People want to applescript and automate and create workflows that the developers did not envisage.

Is it not better to have a non - sandboxed app running signed by an actual developer, than an unsigned app running?

It seems that the current plan for sandboxing will reduce security greatly.

Leave a Comment