What's new in programming--Cocoa

A lot has changed since the last time I seriously sat down to write Macintosh software. At that time, we were still using System 7 (I think...) and the Mac was dominated by the now-deprecated and renamed Carbon API. It was a good programmatic API, but didn't provide much application structure.

Fast forward to 2005 and the Macintosh development community (at least the pure-Mac community) is focussed on using Cocoa, Apple's major acquisition from NeXT for development.

I like Cocoa. There is no getting around it, the object-oriented, message- passing system with C underpinnings works very well for me. I have immersed myself in its message dispatch mechanisms and now understand enough to know when I'm killing performance and when I'm saving myself some time and the users some headache. The environment is fast to develop in and lets the developer concentrate on what their program is doing as opposed to dedicating 99.9% of the time to helping the computer understand how the UI is supposed to work.

One huge change for Apple from the original System 7 days is that they have been moving even faster on integrating new user interface ideas and paradigms into the framework. Apple was (and is) still famous for coming up with new ways to envision the UI and providing those to the programming community in a forward-compatible version (a nice way of saying that if you want to put those features in your version that runs on 10.3, you're going to have to do the work to simulate the technology). This has been a pet peeve of many a Macintosh programmer for years, but I think it's lead to a healthy respect for upgrading to the next version of the OS in the Macintosh community and more freedom for the developers, who unlike their Windows counterparts, aren't supporting a 10-year+ old operating system for 90% of their features today.

As such, the software will work on OS X 10.4.x and nothing earlier, because I can't live without the cool new features that I get for free under 10.4. Besides, we need to keep Apple healthy so that there's a market for this, so getting people to keep their machines upgraded is a good thing.

Cool Cocoa Features

Cocoa itself is an application framework built on Objective-C, a variant of the C programming language. Among the best new features in Cocoa, is Cocoa Bindings, a way to programmatically, or through GUI UI tools, tie variables together with the information they need. Perhaps the most alluring part of this feature is the fact that it uses the same type of object-observing that I've been a fan of for years (usually implemented using C++ classes), but enshrines it into the language and ties it effortlessly into the GUI building tools. Bindings are the glue that ties the UI to the underlying data and it's a great way to keep everything in sync while keeping the line count low on your source files.

Core Data is another very nice technology that Apple has introduced in Tiger. Unfortunately, for my use it's just not fast enough, but I would strongly encourage its use for applications that manipulate 100's or 1000's of pieces of data (or maybe even 10's of 1000's). Unfortunately, the new application has to deal with hundreds of thousands, so it's just not worth it. The technology is great if you've got need for database capabilities in a program, though, since you can let the OS worry about keeping track of all of the data for you and you just need to put the UI on it. When I converted the blogging tool that I wrote when I started the 'Pages, I was able to remove about 70% of the code from the system since I no longer had to manage the data. On top of that, new features were easy to implement. The most significant shortfall (besides some performance issues with large datasets) is that it is difficult, but not impossible, to work with abstract classes. There are some other annoyances, like the way that you have to implement custom classes that contain data other than numbers and strings, but there are well-published work-arounds for these and they're elegant. Further, you can effectively mix Core Data with "normal" Objective-C without hardly noticing it. And, as one final feather in the cap of Apple for this technology, you can remove it completely without much difficulty as the same UI tools that work with Models (for Core Data) work with standard Objective-C objects (like NSArrays and NSSets).

Bundles and Frameworks

Apple's fond of making things easier on the user, and that's definitely a good thing (especially speaking as a user). One of the ways that they've classically done this is by encouraging programmers to make their Applications install with drag-and-drop. Unlike the Windows platform, with DLLs and all sorts of menacing things, almost all Macintosh programs, including such behemoths as Microsoft Word, can be installed through drag-and-drop. In the old days, this meant that absolutely everything had to fit into a single file. We had things called Resource Forks that kept the program, UI design, and other miscellaneous data in one neat little package. Unfortunately, as the world got more complex, these Resource Forks became unwieldy and difficult to use. And, true to form, Macintosh developers had to take on a lot of work to stick data that would otherwise go into ancillary files on a Windows machine and stick them into the Resource Fork.

Well, when OS X came along (and somewhat before on later versions of OS 9), the world changed. All of a sudden, Apple discouraged the use of Resource Forks in deference to something called a Bundle. A Bundle is really a folder or a directory that the OS knows is supposed to be treated as if it is a file. Pretty much every program you use on a Mac now is a Bundle, and if you want to confirm this, do a ctrl-click (or right click, you have a Mighty Mouse) on any application file in the finder and you will see an item for Show Package Contents. So, this is all very cool for Macintosh developers because some times you just need a large number of files to support what you are doing and it's a great place to shove them. If you have a table that you download during an update, your software can automatically get it from the Internet and stick it inside of the program, so that the user can put it anywhere they want-- without fear of breaking the software.

Frameworks are another nice touch for developers from Apple. These are encapsulations of code, data, and interface specifications that allow you to build the equivalent of a dynamically linked library that references other files. It may seem complex and silly at first, but some of the stuff that I'm working on now uses open source libraries that need ancillary data files. By using a framework, I can encapsulate all of these pieces and update it separately from the main part of the software, which is great.

XCode

Back when I started writing code for the NCSA Telnet, the standard environment was something called MPW (the Macintosh Programmer's Workshop) from Apple. It had an inefficient, but robust compiler and an environment that reminded users quite a bit of UNIX (foreshadowing?). In the 1990's, especially with the move from Motorola's 68000-series processors to the PowerPC, everybody who was anybody moved their development to CodeWarrior. CW was elegant, blazingly fast, and extremely friendly for people who wanted to make software that worked in both the 68000 and PowerPC environments (much more so than Apple's own MPW). MPW died a relatively obscure death and CodeWarrior took over the world. Fast-forward to today and the folks who own CodeWarrior right now are more interested in programming mobile phones and game boxes than Macintoshes and so Apple set out, prior to the OS X transition, to create a new development environment. Originally named Project Builder (a throwback to the NeXT days) and renamed XCode, the environment has had 5 years to become competitive and it is now a serious development environment. Having worked in most of the big ones (Microsoft's, CodeWarrior, and plenty of Unix and Java environments), I can say that I really like XCode. There are times when its dedication to the GUI can get a bit annoying, but in the end it is a quite- fast environment with a lot of intelligence built in. And, by the way, it's the only way you're going to get your software running on the Intel Macintoshes.