Apple's Overall Strategy for Frameworks

Colin Wheeler asks if Apple has a large-scale strategy for Cocoa. That is, he wonders if they just figure it out as they go or if there are plans for future releases. A bit of both, I think.

Here's what Colin says about Core data:

In Core Data you got data persistence, database-like querying and the ability to save data in 3 different formats with barely any effort.

When Tiger came out I thought to myself "Wow is this a grand strategy Apple has? Or are they just following up on the next logical step to make Cocoa better?"

The case of Bindings and Core Data is fairly easy to answer. OpenStep had a long track record with Enterprise Objects Framework before Mac OS X came along, and it's still used in WebObjects.

Apple could have just brought EOF straight across, but someone at Apple smartly realized that consumer desktop applications are more likely to have local data stores than remote ones. True, EOF could manipulate local files, but there are bits of API that suddenly don't make as much sense if you don't have a remote database.

So instead of trying to jam something together, they made the courageous decision to start from scratch. This is almost entirely unheard of when you have working code. It took a couple of major releases, but we have now have a very EOF-like framework which is specifically targeted for desktop applications, along with data modeling tools.

In this case, Apple almost certainly knew back in the 10.2-ish timeframe that they wanted to get to Core Data since it has proven value. All applications deal in data. Still, it's clear that the exact implementation details evolved while Tiger was in development — at least some of which was based on developer feedback.

Start With Something Simple

Core Data, in a sense, wasn't new API. It was a re-implementation of an existing framework. New frameworks are tricker to get right, and it's unlikely they're planned so far in advance. This is as it should be, I think.

The most important thing you will ever learn as a developer is this: start with the simplest thing that works correctly, and see where it takes you. This always leads you in the right direction because you're not trying to solve problems that you don't understand yet.

Instead of trying to guess at what you'll need ahead of time, just leave yourself room to make changes as necessary. Cocoa's dynamic design is ideal for this model. Not only is it less stress and more fun, but it leaves you with a much better final product.  

As a novice, it's tempting to try to take on a larger challenge by designing something more sophisticated. I think there's some concern about embarrassment from showing off code that's too simple. Tune that out. Good code is simple code that works correctly.

Needs Drive New API

In Mac OS X, public frameworks often start life as private API in an Apple application, and are put through their paces in real-world use before they're released to developers. This step is critical. It's not just so the code is more complete by the time it reaches developers, but it has to be solid enough so it that won't change in an incompatible way in the next release.

I think it's likely Core Animation came as a direct result of the work Apple did on Motion and the other Pro apps. The app teams set out to build the best apps they can and generalize the resulting code where it makes sense to. Apple probably knew they wanted a specialized graphics toolkit, but didn't have the particular details mapped out ahead of time.

Colin wraps up his post with this:

One interesting trend I see repeating itself over and over is that of Apple coming up with some great custom control (usually used in iLife) and then Cocoa developers working on their own custom implementation of that control, then Apple releases it officially in the next SDK for Mac OS X. I wonder how long that will continue?

I expect this will continue for a while. For the apps and OS to stay in sync, Apple would either have to start adding framework features between major releases (very unlikely) or hold up the release of apps for OS releases (even more unlikely).

Java Support in Frameworks

One of the comments in Colin's article suggests that Java support in Cocoa was deprecated in order to make it hard to port Cocoa apps to other platforms. I don't think this is true.

It's certainly no secret that Apple wants Mac-only apps, and I think it's perfectly reasonable. Exclusive apps draw users in, which sustains an ecosystem that we all rely on. That's why they put huge amounts of effort in Mac OS X frameworks and tools and then give them away.

It's not a matter of trapping developers. There are simply things you can do on Mac OS X that aren't possible elsewhere. The high-level APIs rely on the lower-level plumbing. Your options are to take advantage of that or target the lowest common denominator and hope both platforms will accept that.

All of this is beside the point, though. Cocoa-Java applications that used Cocoa classes wouldn't just run as-is on Windows because Java has its own set of frameworks. The most important thing Java support did was make the syntax more familiar. As far as I know, you can still call Java code from Objective-C apps, it's just that no new Java bridging code will be added.

I think Apple took the stance it did on Cocoa-Java because very few people seemed to be actually shipping anything that used it and the language doesn't have dynamic runtime features that are needed to make things like Cocoa Bindings and Core Data work well.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.