App development and Frameworks

Paul Kafasis of the independedent mac development company Rouge Amobea wrote an interesting piece called The Rise of the OS and another called Restarting Innovation that got quite a bit of attention in the mac development world.

Basically Paul says that the OS starts to make a lot of things that were formerly in the domain of third party applications. A modern operating system’s job isnt just to do Task scheduling, network and memory management and put a pretty UI on top of all this: Todays operating systems ship with mail clients, audio/photo/video management software, calendaring, contact management and a lot more. While this seems to be a good thing (You get more for less! Yeah!), it has some serious implications according to Paul: The developers of apps with similar functionality lose their markets and the Users don’t have many apps to chose from, since there is the OS vendor dominating the field.

This discussion began with some ranting about the missing functionality in Apple’s Mail and the fact that no developer wanting to improve that could possibly compete with the free Mail that comes with the OS. The solution proposed was to put Mail’s functionality into a Framework (named “MailKit”) and make it available for other applications. The Webkit framework is a good example for enabling successful applications by putting functionality into a reusable framwork, so why not do it for Mail, too?

I really like the Idea. Sure, Apple could concentrate more on existing frameworks instead of developing new ones, and while I agree with this point, I also think they are on the right track.

Operating systems need to provide the infrastructure that an application lives in. Formerly that was memory management and everything else that you learned in CS, but today’s MVC-driven applications need more things:

They want to share their Data model and make their data interoperable. This gets used more and more, the Address Book Framework is a good example of this, as is Leopard’s Calendar, Notes, and To-Do-List Framework (and some other Framworks that are still under NDA, but that are a huge deal.) A MailKit Framwork would fit right here: Providing a single Mail database to different Mail Applications and exposing functionality for sending and receiving mails. It would make it easy for the user to switch applications, since his actual Mail data is already there, all Mail Apps all access the same store. That’s a huge thing for developers: It doesn’t only cut down development cost for the Data model, it also makes the transition between apps very easy for the user.

In the Controller Layer, there can also be Frameworks, though most of this layser is really specific to the app. The speech Framework is an example, and we will also see some stuff in Leopard that will expose functionality to app developers that Apple used to have for themselves.

The View layer is a classic domain for Frameworks: Nothing here happens without them, as almost everything done here (Buttons, Windows, etc.) comes from AppKit. WebKit falls into this category, it’s a view framework.

This finally brings us to the point of this posting: I think the comparison between the fictional MailKit Framework and Webkit doesn’t fit. One is about shared Data, the other is about (isolated) use of the same view. I really like what Apple does with sharing data, however they can do a lot more. Frameworks are a very good solution of the problems that arise, when the OS is “taking over”. I hope to see ever more future Desktop Applications that work like “Mashups” of these Frameworks, and Leopard is bringing us a huge step into this direction. Also, a Framework that deals with the Data layer has to have the goal of sharing the data, and not only of sharing the model.