Stoned

Monday, 28 April 2003

Well, that didn’t take long to clarify.

On Thursday I wrote about Dan Gillmor’s ill-considered article in the San Jose Mercury News about former NeXT developers releasing successful Mac OS X applications. I particularly took issue with a few comments Gillmor quoted from Andrew Stone, of Stone Design. But I tried to go easy on Stone, because Gillmor only quoted a few choice words, which I had no way of knowing if they were taken out of context.

The very next day, however, Stone clarified his position. On Friday Stone Design released FontSight, a new utility for Mac OS X that adds a WYSIWYG font menu to all Cocoa applications. It’s similar to classic Mac OS extensions like MenuFonts and Action WYSIWYG.

Now the fact that FontSight only works with Cocoa apps is not a problem. Obviously it would be better if it worked with Carbon apps too, but it’s a reasonable limitation. On the old Mac OS, extensions like MenuFonts and Action WYSIWYG did their thing by patching routines in the OS itself. This enabled some tremendously creative software, but it also could lead to serious instability. A stock Mac OS system running nothing but Apple extensions was rock-solid. Start throwing in third-party extensions that patch the system, however, and all bets were off. The problem is that while patching was possible, it was not supported. And when patches conflicted (e.g. two extensions playing games with the same low-memory variable), the likely result was that your entire system crashed.

That’s not how things work on Mac OS X, which is absolutely a change for the better. You can still achieve system wide hacks (see Unsanity’s Haxies), but you can’t do it at the same “one wrong step and your entire machine will crash” level that you could on Mac OS 9.

In addition, because Cocoa apps are by definition built using the same programming frameworks and depend upon the same OS resources, it’s possible to modify or add to those resources to affect all Cocoa applications on a system. This isn’t hacking — it’s a very deliberate feature in Cocoa’s object-oriented design. For example, F-Script is a powerful scripting system for Cocoa applications; F-Script scripts have access to the same Cocoa object model as Objective-C.

I don’t know how Stone’s FontSight is implemented, but I think it’s a reasonable guess that he’s overriding the default menus in Cocoa’s object model. If so, this technique couldn’t possibly work in Carbon applications. Like I said, that FontSight only works in Cocoa apps isn’t a problem — there’s nothing wrong with taking advantage of advanced Cocoa features.

What is a problem, however, is Stone’s description of non-Cocoa applications.

E.g., on the FontSight Developer’s Info page:

FontSight™ works seemlessly [sic] with all Cocoa applications (truly Native [sic] OS X apps) — such as iCal, iPhoto, TextEdit, Mail and every application from Stone Design such as Create® or PhotoToWeb®.

Eric Blair calls Stone out on this laugher, writing:

What the hell does “truly Native OS X apps” mean? As much as I like Cocoa, there’s nothing more OS X native about it than a well written Carbon app. If you compile a Carbon application as a Mach-O binary, it will only run on OS X. Are the folks at Stone Design trying to tell us that such applications aren’t OS X native?

Yes, that’s exactly what they’re trying to tell us. Here’s more, from the FontSight Press Release:

FontSight Features include:

  • adds visual font menu to native OS X Apps

In other words, “native OS X Apps [sic]” means “Cocoa”. And then, in a footnote:

Cocoa is Apple’s revolutionary, native OS X development system. All Stone apps are written in Cocoa, as are Apple’s TextEdit, iCal, iPhoto, Safari, Mail, etc. Carbon applications that have been ported to OS X without taking advantage of the native functionality of OS X do not show the FontSight menu.

Now that’s just downright insulting. The implication is that the only way for developers to “take advantage” of Mac OS X is to use Cocoa. So, e.g., despite the fact that BBEdit 7 integrates with:

  • all Unix shell scripting languages
  • CVS
  • Project Builder

not to mention that it displays a running count of search results in its Dock icon, it’s not “taking advantage of the native functionality of OS X”?

That’s not to say all Mac OS X applications are created equal. Cocoa applications do have certain features not available to Carbon apps. (Likewise, the Carbon APIs have access to features not available with Cocoa alone.) There’s nothing wrong with Cocoa developers promoting these features, either. Stone could have instead simply written something like the following:

“FontSight is implemented using advanced features in Cocoa, Apple’s revolutionary application framework for Mac OS X. The FontSight menu therefore only appears in Cocoa applications, such as all Stone Design apps, as well as Apple’s TextEdit, Mail, Safari, iCal, and iPhoto.”

That’s called promoting your features.

But instead, Stone took the opportunity to besmirch Carbon applications with the claim that they’re “not native”. That’s called bigotry. Just because Carbon developers aren’t taking advantage of Cocoa does not imply they aren’t taking advantage of Mac OS X; Cocoa is a part of the OS, not the OS itself.

Stone and other Cocoa developers can sort of get away with this anti-Carbon bigotry because “native” isn’t a technical description. “Cocoa” is a technical description, as is “mach-o binary”. This application is a Cocoa application. That’s a statement that can be proven true or false. This application is native to Mac OS X. That’s a statement that depends on your meaning of “native”. Stone Design has apparently decided that “native” means “Cocoa”.

Most Mac users have little or no understanding of the actual technical definitions of “Cocoa” or “mach-o” or whatever, nor should they need to. So by equating Cocoa with the adjective “native” — a word whose meaning is seemingly obvious, but actually vaguely defined — Stone creates the impression that anything other than Cocoa is inherently inferior, not genuine, faking it. You don’t want to use a non-native application, do you?

Small Developers

Andrew Stone is obviously very passionate and knowledgeable about the advantages of Cocoa. I’ll say it again: he should feel free to promote those advantages clearly and prominently. As in “Because our apps are Cocoa, you can do this, and this, and this. These features make our apps superior.” Not, “Our apps are superior just because they’re Cocoa.”

Certain executives at Apple haven’t helped in this regard, having insinuated in the past that Carbon is a stop-gap measure on the way to an all-Cocoa future. Many Mac users still believe this is true, but it’s not. Carbon is not just a compatibility layer for old applications; it’s a deep chunk of the OS.

Let’s take a step back for a moment, and imagine that I am wrong, and Andrew Stone is right: that Cocoa applications are inherently superior to Carbon applications. If this is true, what does it mean?

Why, for example, have none of the major Mac applications been rewritten in Cocoa? Microsoft Office is Carbon. So is everything from Adobe. And Macromedia. QuarkXPress 6, whenever it ships, is going to be Carbon. BBEdit and Script Debugger are Carbon.

These are all popular and long-standing Mac applications from premier Mac developers. If Stone is right, why are all of them doing such a disservice to their customers by shipping sub-standard applications?

What is a plausible explanation? That Mac developers are stupid (too stupid to understand Cocoa, or too stupid to recognize its superiority)? Are they lazy? Are they spiteful? If you accept as fact that Carbon applications are inherently inferior to Cocoa ones, you must therefore accept that Mac developers shipping Carbon applications are either incompetent or are knowingly shipping inferior products to their customers.

Do you see how this is insulting? Not just insulting to established Mac developers (although it is), but also to Mac users in general, who are being sold a bill of goods on the assumption that they lack the technical expertise to see through these claims of “nativeness”.

So What Then?

The truth is really kind of boring. Cocoa is an application framework. It’s an excellent development system, but still, it’s just a framework. An application framework handles all the generic stuff common to all applications — windows, menus, buttons, mouse clicks, the event loop, etc. If you open Project Builder and create a new default Cocoa project, you start with a working application — you can compile it and you get a double-clickable application with a menu bar, an About Box, and more. As a developer, Cocoa handles lots of stuff “for free”.

But a default Cocoa app still doesn’t actually do anything. If you’re developing a vector drawing application, you still need to write the code to do all the vector drawing stuff. If you’re writing an accounting package, you need to write all the accounting logic and features. Makes sense, right? Using an application framework like Cocoa to manage the generic details frees developers to concentrate on what it is their apps are supposed to do.

But no matter how good Cocoa is, it’s a bit narrow-minded to assume it’s the one and only legitimate application framework for Mac OS X. For one thing, many long-time Mac developers have their own frameworks, written from the ground up for their specific needs. E.g. Adobe, we might assume, has an application framework optimized for graphic-intensive applications. Adobe applications share a similar and distinctive human interface; for example, Adobe’s tabbed palettes are an innovative (and patented) feature that the company clearly considers a competitive advantage. Could Adobe re-implement tabbed palettes in Cocoa? Of course — but they’ve already implemented them in their existing framework.

Or note this: Cocoa has some significant shortcomings. Its support for AppleScript is mediocre, at best. Bare Bones’s BBEdit and Mailsmith are not only fully scriptable, they’re recordable. Cocoa does offer some AppleScript support, but it pales in comparison to BBEdit’s.

So the point is this: many of the advantages to Cocoa are for new projects. Unquestionably it’s more work for a developer to write their own application framework, but if they’ve already done it, and have been working with it for years, there’s little or no advantage to switching now.

Shouldn’t we safely assume that top Mac developers know more about the internal structure and framework of their applications than we do? Shouldn’t we decide which applications to use — like, say, whether to use Adobe Illustrator or Stone Design’s Create — based on what they do, rather than how they’re made?

Postscript, Delivered with a Satisfied Smirk

And by the way, isn’t Cocoa’s standard Font Panel palette supposed to obsolete the old-fashioned Font menu? Just curious.