Doubting Cocoa

TidBITS, iMovie 3 Tips and Gotchas:

“Although the program introduced a number of welcome new features, performance was sluggish, the program crashed for no reason, and exporting data was problematic. iMovie 3 had become the new Word 6 (for those who remember that giant step backwards).”

I still wonder about performance sometimes. Why is iCal so slow anyway? And why is the rewritten-in-Cocoa iMovie 3 slower than iMovie 1 and 2? No doubt that it is design decisions more than the language or framework that makes an app slow. OmniOutliner and Keynote are two examples of fast Cocoa apps.

I spent several weeks last month working on Cocoa experiments — small test applications and new features in a Carbon application. It’s clear that the Cocoa framework is very powerful. If I started a new application from scratch I would probably use Cocoa, but for an existing Carbon application the choice is more difficult.

Look at apps like iTunes. It’s still all Carbon, even the new music store. Or Final Cut Pro. These are some of Apple’s best apps. Not to mention Photoshop and Illustrator. Why should I abandon Carbon if it produces apps like these?

And there’s something else: I trust the Carbon team at Apple. They know the Mac better than most — not just the APIs but what it takes to build solid apps, and what the essence of Mac UI is all about.

I need to think about this more. Contrary to my previous post, mixing Cocoa and Carbon windows in the same application is problematic. Window focus doesn’t always work correctly, and dealing with menu commands in two different ways complicates the app. A better approach would be to stick with one framework for the UI (Cocoa or HIToolbox), and mix-and-match Cocoa and Carbon as needed under the hood.