Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
What's a Mac application? This is not just a rhetorical question. Mac users tend to be more passionate about their choice of computing platform than Windows users, in part because the Mac offers a distinctive and elegant user experience. So, it follows that a "Mac application" has some distinctive and elegant qualities--particularly features that can't be found on other platforms.
Some Mac users and developers are quite opinionated, and quite specific, about what makes a Mac application: it has to be written in Cocoa, Apple's Objective-C application framework. These developers represent the far extreme of the Cocoa enthusiasts, but they are by no means alone in their position. The dead giveaway is their hostility to Apple's Carbon framework: "Carbon is not a 'true' or 'good' OS interface: it's just a helper for 'legacy' MacOS code and was supposed to be fully abandoned once development teams got up to speed with Cocoa."
I have to disagree with their viewpoint here. A Mac application, at its most fundamental, is an application that takes advantage of Mac features. As I've said before, Cocoa provides access to those features--but so does Carbon. Via Carbon, my own applications take advantage of Apple's built-in help system; they hook into Apple's native print frameworks; they use dock badges, and other visual notification cues; and more. Additionally, I'm continually refining the user interface of my programs to bring them more in line with the prevailing, modern look-and-feel on OS X. My programs, though written with a cross-platform toolkit, would not run on another platform in their current state.
It's true that some aspects of my programs' interfaces don't hook into the standard Mac approach. My toolbars don't build on Carbon's toolbar components. My search field doesn't build on Carbon's search field components. That's a limit of the underlying GUI toolkit that I use (which is, incidentally, built on Carbon). So be it.
What's more important is that my applications work, and work well. They have good documentation, are easy to install, are easy to use, and have a responsive developer supporting them. They also integrate with Mac-specific features as much as possible. All of these aspects of my applications work together to afford a good user experience. And I'm always trying to improve that user experience; if a user has a suggestion that will improve the experience my programs provide, I implement those suggestions whenever possible. The main list of new things I'm adding to my programs right now are user suggestions.
What isn't in the cards, at least for the foreseeable future, is a rewrite of my applications in Cocoa or even a spiffier Carbon wrapper, such as RealBasic or wxPython. Oh, I've tried. I've downloaded countless tutorials, played with code samples, and even purchased some books and some software. But I never get very far. As soon as I start, I look at how different the other approaches are from my current approach, especially Cocoa, and my eyes glaze over. I look at the thousands of lines of code I've written over the past few years--functional, stable code that has gone through endless revision and refinement--and I wonder why I would consider rewriting all that code, just to gain some marginal improvements in the appearance of my programs. As a far more experienced developer than me once wrote: "When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years."
It isn't necessary to use Cocoa to write Mac applications. I'm a Mac developer, using Carbon. And I write Mac applications.