On Sep 11, 2006, at 12:52 AM, David Niemeijer wrote:
Apple wants to keep is message simple to end-users so they come up
with these kind of statements, maybe also partly as an excuse for
not making iTunes accessible.
From one of Apple's accessibility tech docs:
--begin excerpt
"Modifying your application to use the appropriate Carbon or Cocoa
frameworks may require significant work, but doing so has [important
benefits].
It extends the effective lifetime of your application, because many
of Apple's future innovations and performance increases will be built
upon these frameworks (especially Cocoa).'
--end excerpt
I didn't add the parenthetical (especially Cocoa) bit. That's a not-
so-subtle hint from Apple...and not the only not-so-subtle hint one
can pick up in the documentation.
Carbon vs. Cocoa is not a binary choice (particularly because Cocoa
borrows from/or wraps Carbon). If you have an existing Carbon
codebase, it might make sense to develop in Carbon. Rewrite? Maybe
not. I am - rewriting, that is - but I'm working with relatively
small apps for which a rewrite doesn't seem particularly daunting. In
fact, with Objective-C/Cocoa there will be significantly fewer lines
of code and I'll be getting lots more for "free" with Cocoa.
Certainly the app will be easier to maintain once completely
rewritten in Objective-C/Cocoa (there's that sustainability thing
again)...easier than it would be in Carbon.
Anyway, the fact that the lines blur does not mean Carbon - used
'exclusively and directly' - is still a good choice...particularly if
you're developing your app from scratch and looking to sustain the
app (and, yes, compete) well into the future. To be clear, I'm not
suggesting that Carbon apps can't be great apps. They certainly can
be...and accessible, with some caveats.
That being said, an interesting post from one of the Mac tech blogs
hits on some of the subtleties while shedding some light on why it
might be a good idea for developers to think seriously about choosing
Cocoa over Carbon:
--begin excerpt
'...up-and-comers who start with Cocoa will have an easier time
matching [your Carbon] feature set. Cocoa gives increased firepower
to your competition.
Cocoa is old, but it builds its concepts at a higher level than
Carbon. In many ways, with the merging of Cocoa and Carbon on OS X,
Cocoa has become a wrapper of Carbon (or CoreFoundation, which became
part of Carbon). The very fact that one can wrap the other speaks to
the power it brings. What’s often overlooked is that Cocoa would be
useless without Carbon (or Posix, or something else) filling in all
the functionality cracks below the surface. On OS X, Carbon is part
of the supporting cast that makes Cocoa possible. But for legacy
application’s like Office, Photoshop, etc. that use Carbon
exclusively and directly, they’re writing much of the “wrapper code”
themselves. You’ve got your own document manager, you’re managing
value change notifications, implementing an undo stack, etc.
If it’s not broken, don’t fix it. Right? But if it is broken in
subtle ways that cause a disconnect between “the old way and the new
way,” then you’re stuck fixing it in *your* wrapper instead of
getting it for free in Cocoa.
But worst of all for Carbon developers, it’s become clear that Apple
favors Cocoa in many of it’s new technologies. Compare embedding a
WebKit view into Cocoa vs. Carbon. Apple can’t afford to drop support
outright for either framework. But as compromises continue to be
made, I’m sure I know which framework will get treated as second-class.'
--end excerpt
So, the (progressively more vigorous) nods towards Cocoa may be more
than just PR-simplicity or excuses for the inaccessibility of certain
flagship Apple apps.
Joe
