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.
Design Element
Apple's Overall Strategy for Frameworks
Posted Dec 12, 2006 — 13 comments below




 

Chris — Dec 12, 06 2651

Yup, you're on target. Apple doesn't have a Grand Unified Frameworks strategy, but it does have longer-term occasional 'story arcs', if you will, such as Core Video, animation, and Core Data.

Apple actually had a number of system apps implemented in Cocoa-Java at one time, but ported them (in some cases ported them back) to Objective-C because they were losing a lot of performance. Java added another dynamic runtime layer onto Objective-C, which itself has a nontrivial amount of dynamic indirection. Not speedy.

CocoaJava was originally an attempt to co-opt the circa-2000 level of hype around the Java language, as well as quelling developer angst over the ObjC syntax. (They tried but were unable to come up with a workable Algol-like syntax for ObjC that ObjC partisans didn't hate.) I don't think Apple would have bothered with it in today's environment.

Andras Puiz — Dec 12, 06 2656

I'm confused by the way Apple made WebObjects Java only, thus killing a Cocoa EOF, and now they are adding it back bit by piece. Remote database connectivity is something developers have been begging of Apple to add to Cocoa. I hope it will arrive one day...

Scott Stevenson — Dec 12, 06 2658 Scotty the Leopard

I'm confused by the way Apple made WebObjects Java only, thus killing a Cocoa EOF, and now they are adding it back bit by piece

It's certainly confusing if you think of EOF and Core Data as the same, but they're actually different. The two are compared here.

leeg — Dec 13, 06 2673

I agree with Chris and his idea of "story arcs" flowing through Mac OS X. IMO 10.0-10.2 was "In which OPENSTEP finds its way onto the consumer desktop", and 10.3-10.*5* (basically, the addition of Cocoa Bindings, Core Data and ObjC 2 properties) is "In which the Model and Controller are done for, as Interface Builder did for the View". Simultaneously there have been other stories at other levels, for instance "In which Darwin enters the 21st Century" followed by "In which Darwin becomes an innovator in the UNIX world".

As the computer next to this iBook is a 1ft magnesium cube, I was one of the people who mourned the loss of ObjC-EOF. OTOH there *were* only ever a few tens of thousands of such people, compared with tens of millions waiting for a desktop OS which sucked less than Mac OS 8.

Andrew L — Dec 13, 06 2678

I'm working on a number of WO projects and despite a strong Obj-C background on OPENSTEP, it seems like EOF and WO in java was a sensible and necessary move to me.

How long were they going to keep maintaining FoundationKit on various versions of Solaris and Win32? What about those platforms that are not on the supported list such as LINUX? What about on-going database and LDAP driver development for EOF/Obj-C? As far as I can see, the java platform and technologies like JNDI and JDBC solve these basic problems and at the same time, open up a huge range of opportunity for integration with other J2EE systems. I think it was a good move.

Karl Gretton — Dec 14, 06 2694

I concur with the last comment from Andrew L. Having use WO both in its Obj-C days and in more recent times, WO was held back by many issues that existed in the underlying Apple frameworks.

It seems that Obj-C is ideally suited to desktop applications. As anyone reading this post knows, amazing applications can be created with very little code - compared with the mess that the typical M$ Visual Studio application generates or Eclipse/Java. However, it never seemed to scale for WO.

EOF had many performance issues around multi-threading, concurrent request handling, faulting issues within its various layers (EOAccess, EODatabaseContext, etc). Following the 'auto-port' (Apple just basically put their EOF code through the sausage grinder Obj-C to Java conversion utility), most of these issues have been thoroughly addressed and WO now runs beautifully in Java - much better, in my view, than it ever did with Obj-C.

And Andrew is right. As soon as a new OS, DB or anything else arrives on the scene, we have the necessary drivers to use it, rather than waiting for an Apple release cycle.

So Java for the server side and Obj-C for the desktop.

cjwl — Dec 14, 06 2698

I would definitely agree that there is no grand plan, while Apple has done a good job of keeping Cocoa cohesive there have been a lot of growing pains over the years especially before OS X. Objective-C EOF went through major revisions which severely broke backward compatibility and before that was DBkit, there was a definite learning experience through the years. Some EOF concepts such as Key Value Coding were merged into Foundation before Core Data came along, making the EOF-y concepts in CoreData a more natural evolution for Cocoa developers. Objective-C EOF was far more complex than CoreData is, I suspect it would have not been well received by Mac desktop developers.

Foundation and to a lesser extent AppKit went through fits of refinement pre OS X. AppKit had already gone through a major overhaul in the appkit -> AppKit OpenStep transition, Foundation went through revisions and dropped classes during the YellowBox and WebObjects period. There was the whole thing with replacing DPS under the hood too. Cocoa was pretty stagnant in the pre-10.0->10.2 days while Apple overhauled everything else so we have had a settling period of the API's which gives the appearance of grand design. Cocoa has become more of a moving target these days now that the growing pains of OS X are largely over and I think we will see things come and go as it evolves more.

I believe the Java Cocoa support was dumped because it was not well received, this seems obvious just from the general vibe coming off the developer community. There was a lot of work put into the Java bridge for WebObjects so it was relatively easy to jump on the Java bandwagon with Cocoa. But there weren't good enough reasons to use it, you lost one of the major reasons for using Java, supposed portability, and the Java GUI kits were becoming Good Enough. On top of that people who wanted to write native Mac apps seemed OK with Objective-C/C/C++. I know people who have done large Java apps for the Mac and they did not use Java Cocoa, they still want the cross-platform parachute and I can't blame them.

Really, if Apple wanted to make it harder to port Cocoa programs to other platforms they would have stuck with and forced everyone onto Java Cocoa with the bridge. What a goddamn nightmare to emulate and completely unpleasant to do. It is easy to compile Objective-C with gcc on most platforms, all you need to do is write the frameworks which you would have to do with Java Cocoa anyway.

leeg — Dec 14, 06 2704

cjwl: don't even need to write the frameworks on other platforms, those nice people over at GNUstep have done most of that for you. We even have a Java bridge...

Scott Stevenson — Dec 14, 06 2705 Scotty the Leopard

those nice people over at GNUstep have done most of that for you

GNUstep is a great project (I did the web site design a ways back), but it's quite different than Cocoa, particularly since most Cocoa apps are more than just AppKit and Foundation.

cjwl — Dec 15, 06 2710

GNUStep? Oh damn! I am always the last person to find these things out.

Andras Puiz — Dec 15, 06 2712

Well, I know that CoreData is not EOF. But I'm sure remote database connectivity will come to CoreData one day, and of course, Apple won't admit that until it's ready to announce the feature at a WWDC. When that happens, the document you've linked will change to reflect that.

Isn't it a logical next step (no pun intended) to extend CoreData to other databases besides SQLite?

Scott Stevenson — Dec 15, 06 2714 Scotty the Leopard

Well, I know that CoreData is not EOF. But I'm sure remote database connectivity will come to CoreData one day, and of course

That's quite possible, but Core Data with remote database access is different than EOF. Core Data has a desktop-first mentality that EOF doesn't.

zen — Feb 01, 09 6601

nice post!




 

Comments Temporarily Disabled

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





Copyright © Scott Stevenson 2004-2015