Daniel Eran Dilger
Random header image... Refresh for more!

WWDC 2008: Is Mac OS X 10.6 the Death of Carbon?

carbon vs cocoa
Daniel Eran Dilger
Just as pundits have worked to incite drama about the death of PowerPC, Apple’s two key development APIs in Mac OS X, Carbon and Cocoa, have been frequently personified as rivals dueling to the death. Will OS X 10.6 finally mark the end of Carbon?

Why Mac OS X has Two Main APIs.
In 1997, Steve Jobs returned to Apple and gained control over the largest desktop software platform outside of Windows. For the previous ten years, Jobs had been promoting a new platform at NeXT, which advanced upon Apple’s graphical interface with a UNIX underpinning underneath and an advanced set of development frameworks on top. That product, known as NEXTSTEP, was suffocated in the market in the early 90s between Apple’s consumer and creative stronghold and the increasing ubiquity of Microsoft’s Windows.

Apple sued NeXT to prevent it from entering the consumer market, and Microsoft worked hard to prevent it from gaining any exposure, worried that its own tepid undertakings with OS/2 then Windows NT would be blown out of the water by NeXT’s far superior, already existing technology built on top of UNIX. DOS vendor Bill Gates famously fumed that rather than developing for NeXTSTEP, he’d “piss on it,” and he personally delivered the vaporware “vision” of Cairo in 1991 with the direct intent of neutralizing any interest in the excellent technology that already existed in NEXTSTEP in favor of promises that Microsoft would deliver the same thing at some point. It never did.

Despite limited sales, NEXTSTEP powered a number of significant developments in the early 90s, including work by Tim Berners-Lee to develop the web, pioneering development efforts in video games by John Carmack of id software, and custom application development among clients in securities banking and intelligence services, each of whom had needs unaddressed by DOS and the rest of the market.

With the fusion of Apple’s market position and NeXT’s technology in 1996, Jobs’ development team hoped to quickly migrate Mac users and developers to the NEXTSTEP tools. Advanced under the name Rhapsody, the plan intended to essentially modify the look of NEXTSTEP to be more familiar to Mac users and update its core OS to roll in recent advances. Large Mac developers rejected the move, as it would have forced them to rewrite their apps from scratch or else have them run in a second tier compatibility box.

At the time, Apple’s fortunes weren’t exactly inspiring confidence, so developers were hesitant to jump on the company’s latest strategy and invest significant resources in an unproven plan by a vendor that had repeatedly dropped, sidelined, and materially changed its development roadmap too many times over the last half decade already.

 Cocoa and the Death of Yellow Box and RhapsodyCocoa and the Death of Yellow Box and Rhapsody

Cocoa and the Death of Yellow Box and Rhapsody
Why OS X is on the iPhone, but not the PC
SCO, Linux, and Microsoft in the History of OS: 1990s

Introducing Carbon and Cocoa.
To pacify its existing developer base, Apple announced two sets of “Application Programming Interfaces,” describing independent approaches to creating applications that would run on Mac OS X. The existing Classic Mac OS APIs would be cleaned up and modernized under the name Carbon. Existing Mac OS apps could be “carbonized” by making relatively minor changes that would allow them to run cleanly against the Carbon API in development on Mac OS X, while also running on the existing Classic Mac OS 8/9 with the CarbonLib plugin.

For developers who wanted to target both existing Mac users and future users of Mac OS X, Carbon was the only choice available. Apps that were not carbonized would only work on existing versions of the Classic Mac OS or in a specialized compatibility environment under Mac OS X called Classic or the Blue Box.

The minority of developers already familiar with NEXTSTEP could continue to develop using the NeXT frameworks APIs, now called Cocoa and briefly referred to as Yellow Box. Between 1997 and 2002, when the first mainstream version of Mac OS X was released, Apple had to focus on maintaining support for existing Classic Mac OS users. That required getting Carbon up and ready so that existing applications could run on the Macs Apple was selling, and so that those apps could be migrated to the upcoming Mac OS X as smoothly as possible.

Between 2002 and 2005, Apple worked hard to push out regular references releases and frequent updates that brought Mac OS X from a brand new system into the realm of being a reliable, secure, and well performing operating system. During that period, users began seeing a difference between applications built from Cocoa and those developed in Carbon. For example, there were differences in appearance and consistency, because Carbon let and/or forced developers do their own thing, while Cocoa provided more given functionality for free.

Carbon vs Cocoa: Hype Wars.
However, the actual differences between Carbon and Cocoa were often overblown by pundits who made sweeping generalizations based entirely upon abstracted marketing names. Cocoa and Carbon did not develop as completely independent toolsets. Because so much of the Classic Mac OS and NEXTSTEP functionally overlapped, Apple made a number of major changes in Mac OS X that pulled from both.

The power of NEXTSTEP’s frameworks came from object oriented development, where code objects are treated as units of behavior and data that can be organized into a class hierarchy with inherited features, easily modified into a similar but distinct subclass, and reused frequently. Classic Mac OS programming followed a more procedural model, where everything is written by hand in custom code that can be relatively harder to reuse or repurpose.

In order to preserve the benefits of NeXT’s object oriented Cocoa while bringing forward support for classic procedural development, Apple defined a large number of core system functions as procedural APIs, and built object oriented frameworks on top. Rather than being opposite toolsets, Cocoa is in many respects an alternative, object oriented way of accessing the procedural core of Mac OS X. That means Carbon can’t really go away entirely, because Cocoa relies on it.

Carbon Dated.
At the same time however, it makes increasingly less sense for Apple to promote Carbon development to third party developers, as doing so requires Apple to build both procedural and object oriented interfaces for each new framework created. Apple has been focusing attention on Cocoa for several years now, and clearly wants developers to migrate toward it. When they do, developers can get a lot of functionality for free as Apple updates and refines Cocoa.

Applications often use a mixture of both APIs. Historically, developers have had to rely on Carbon because Cocoa didn’t always address their every need. In part, that was originally because Apple was focusing on getting Carbon finished, and so did not have the resources to complete everything in Cocoa. Since Mac OS X 10.4 Tiger, the emphasis has very obviously swung to Cocoa because the effort needed to advance Carbon was complete; there were no more apps to transition from the old Mac OS. In the future, Apple will continue to promote development in Cocoa.

That’s already the case on the iPhone, which only offers a Cocoa interface. There’s no need to shoehorn in old Classic Mac OS apps, so there’s no need for Carbon. The iPhone therefore marks the return of Jobs’ clean NEXTSTEP, unadulterated by two decades of Mac OS legacy. What the iPhone offers today is what the desktop will offer in the future. That doesn’t mean Carbon’s procedural programming will be yanked from the body of Mac OS X, but it will be put to pasture rather than being incrementally maintained in lockstep with Cocoa.

The Return of Rhapsody.
At some point, Mac OS X will begin to look a lot like Rhapsody: applications will all be Cocoa apps. That will take some time, but the writing is on the wall and has been for years. The most obvious evidence of this was the announcement last year that 64-bit graphical interface APIs would not be exposed in Carbon, but only in Cocoa. That means any developers wanting to make use of 64-bit applications in Leopard will need to at least build their interface using Cocoa.

Apple is pushing a Rhapsody-like strategy now because it finally can. In the late 90s, Apple desperately needed Adobe, Microsoft, and other big developers to support its plans just to get Mac OS X off the ground. Now the tables are turned. Apple can dictate what developers need to do, and push them to use more modern tools because the company has a far stronger user base and forward momentum. In the case of the iPhone, Apple is starting from a clean slate.

The immediate advantage of pushing developers to Cocoa will be a more consistent user interface, better support for resolution independence, faster development, cleaner code, and less code, because Cocoa does more heavy lifting itself. Another benefit to moving decisively to Cocoa is the prospect that Apple could port the Cocoa API to other platforms, allowing developers to create applications using Xcode that could be deployed on both Mac OS X and Windows. Such an effort would pull wind from the sails of Microsoft’s .NET while focusing more attention on Cocoa just as developers are expressing a lot of interest in the iPhone.

Cuckoo for Cocoa: Is Safari on Windows the next iTunes?

Cuckoo for Cocoa: Is Safari on Windows the next iTunes?
Safari’s Controversial Potential as a New Yellow Box for Windows
Advancing Software Reuse of Linux, Windows Code on the Mac

Mac OS X 10.6 Snow Leopard, Carbon, and the Future.
While Apple clearly wants developers to use Cocoa, it simply can’t remove Carbon, and has no compelling reason to attempt to do so. The upcoming version of 10.6 will continue to run Carbon code, and support ongoing Carbon development.

As noted in WWDC 2008: Is Mac OS X 10.6 the Death of PowerPC?, Snow Leopard has been confirmed by multiple, independent sources as not introducing any new marketing features. One source noted “What this release does is clean up some stuff that needed it badly over the years and position Apple to focus on a single platform and get rolling with a faster leaner release cycle.”

In addition to continuing work under the hood in the areas of resolution independence and kernel level security, sources report that 10.6 Snow Leopard will also introduce the new concept of blocks, which will be covered in more depth at WWDC.

WWDC 2008: New in Mac OS X Snow Leopard

WWDC 2008: Predictions & What to Expect: Mac OS X 10.6
WWDC 2008: Future UI Designs in Mac OS X 10.6
WWDC 2008: Moscone West Spy Shots!

I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Technorati Tags: , , , ,

  • Pingback: WWDC 2008: Is Mac OS X 10.6 the Death of PowerPC? — RoughlyDrafted Magazine()

  • nat

    Wow, and I thought we wouldn’t see a new iteration of OS X for a year, maybe two! :D Leopard just seemed so advanced, I thought there was no need for a new release after just a year and a half. I also thought Ars’ Snow Leopard prediction was bs, ’til you explained why it makes sense.

    Still getting daily use out of my two year old Tiger-running 15″ PowerBook G4 that’s very capable of running Leopard, I don’t mind the idea of Snow Leopard being Intel only. All the anti-Apple tech media sites like to make backwards compatibility a major issue when in reality Tiger is in many ways more advanced than Vista, Panther is still quite good, and Leopard could last me another few years (if Apple hadn’t released the MacBook Air; just double the hard drive or the SSD and I’ll buy one Jobs).

    Apple has been innovating so much, now they can go back and flesh out any overlooked apps, services, UI designs, etc. and they’ll run even faster with Intel-optimized code.

  • dicklacara

    Another benefit to moving decisively to Cocoa is the prospect that Apple could port the Cocoa API to other platforms, allowing developers to create applications using Xcode that could be deployed on both Mac OS X and Windows. Such an effort would pull wind from the sails of Microsoft’s .NET while focusing more attention on Cocoa just as developers are expressing a lot of interest in the iPhone.

    Daniel, care to expand on how Cocoa/XCode could be used for Win apps without re-implementing both .Net and Win32 APIs?

  • Pingback: Mac OS X 10.6 "Snow Leopard" to arrive Jan '09 - Page 2 - MacNN Forums()

  • retnuh


    Flip it around, if cocoa sits on top of carbon, then why couldn’t cocoa sit on top of the win32api? It would make OS X apps run on windows, not windows apps run on OS X.

    There’s good and bad there that I won’t go to much into, but while technically feasible it would be a crap ton of work. And while at first glance might not make much sense, its the long term that would matter. Control of the API, its Microsoft’s main asset and its becoming more and more irrelevant as more focus is put towards web applications. Hence the panic for “hey everybody switch to .Net, its great”, Silverlight, Live services, etc… they realize they need to hold control of what programmers write to. Now picture 2-3 years forward where you could write an app that needs very little work to go from OS X, Win32/64, iPhone/Touch and it makes it a very interesting market for programmers to enter since they basically code to the largest. That mixed with introducing people to a different way to do things and Apple would get a ton of new exposure for their Macs.

    If Apple has any intension for more windows compatibility this is how I’d see them moving forward.

  • dicklacara

    @ retnuh

    I did mean in order to run OS X apps on Win.

    Thinking out loud, here…

    You are suggesting interfacing Cocoa to MS’s existing win32 and .Net APIs. I was following a long thread on ARS that claimed you needed to use both & they were both crap (or at least incomplete or inconsistently implemented).

    If I understand correctly:

    1) Apple doesn’t need to worry about legacy apps or backward compatibility because these would be new Win apps (or new Win versions of OS X apps)

    2) Given that, Apple could cherry-pick what to interface first with Cocoa and wrapper/passthrough the rest as necessary.

    3) Apple could even make their Cocoa frameworks library available to Win programmers.

    So, MS has all this legacy baggage and is somewhere in the middle of migrating its developers from a bad API to an incomplete one.

    Hmmm… It appears that a more nimble Apple could beat MS at it’s own game:

    1) Add clean Cocoa implementations that are missing or cumbersome in win32 or .Net
    2) Use existing Cocoa implementations to replace corresponding features where appropriate
    3) As MS goes through its long release cycle of new API features, Apple could probably closely follow with a Cocoa implementation

    So, MS has this baggage, that Apple can largely ignore & concentrate on slick new software.

    If Apple did that (maybe they are well along the way) it would certainly create a dilemma for Win programmers.

  • dicklacara

    @ retnuh

    I meant to finish with:

    OS X PPC, OS X Intel, OS X AppleTV, OS X iPhone/ARM… and now OS X Win.

    That’s what I call a Universal Binary app:)

  • http://coderad.net StrictNon-Conformist

    Reading this post and the comments, I do find that an interesting thought, indeed. Windows and Leopard are notably different under the hood in many ways, not just at the kernel API level and the low-level procedural level, but also at higher-level frameworks like .NET and Cocoa.

    There’s what’s known as WINE (Wine Is Not an Emulator) for Linux and a few other similar platforms, which largely provides API compatibility that allows Windows applications to run on the hosting platform, but it really isn’t perfect, and because Microsoft never rests on advancing the number of smaller APIs that are used (DirectX, COM, all the fun names) which many applications might use just enough of to make it impossible to run with any current version of WINE which is developed by a bunch of people on their spare time, the biggest problem with the development of WINE stems from the root of the developers having no inside knowledge of the Windows API and all its nooks and crannies and how it is supposed to operate, versus how it actually operates. This “supposed to” as opposed to “What it really does” is known to change from Windows release to release, in some subtle way, every so often. This is a heck of a lot to try to keep up with, because as ugly as it is, the Win32 API is very powerful, and HUGE! There are portions that don’t seem to have as good of basic functionality that’s developer-friendly as my observation of Cocoa’s frameworks are: the one that comes to mind most readily is how nasty Windows MIDI handling is in comparison.

    Where Apple would have an advantage is this: they don’t need to know absolutely all the gory details of the underlying warts of the Windows API in order to port Cocoa onto the Windows Win32/Win64 base API. As long as they know well enough to map certain things through the user-level API, and (perhaps in the case of the media handling) completely bypass the user-level API and use audio drivers more directly via driver calls, they can reasonably enough keep up with the mutations of Windows over time. With Vista offering a compositing engine, it isn’t a big stretch to readily move the Leopard Cocoa GUI over to Vista intact, though XP and before would be more of a problem, but… XP is going away if only due to hardware dying of old age, and people only being able to buy Vista and get drivers for Vista for newer hardware.

    I can’t help but wonder: is Windows Safari a subversive testbed for a Cocoa-On-Windows layer, and Safari has been used as a beta test of Apple’s low-level API understanding and mapping of Cocoa-Windows functionality? It makes a certain kind of sense: hand out the beta for free… Reading this latest post of Dan’s, it occurs to me that perhaps the two bridges Apple created don’t actually refer to two Apple hardware platforms, but the Apple Cocoa Frameworks going to Apple hardware AND the Apple Cocoa Frameworks going to Windows hardware.

    But that still raises the logical question: the Vista kernel itself isn’t a bad thing, though the drivers may be unstable: the user-space stuff is where things get most mucked up for performance, assuming the drivers are otherwise stable. Does it really make great sense for Apple to release the GUI crown jewels that differentiates Apple hardware/software systems onto the everyday Joe’s generic hardware? Granted, it’d likely be on an application-local basis: the Cocoa Frameworks won’t magically transform an entire Windows Vista system to looking and acting like OS X underneath, and it won’t have much effect on other applications. If Apple is porting the Cocoa Frameworks to Windows, perhaps the reasoning is this: it’ll get users more accustomed to looking at all-things-Mac, and it’ll do the same thing for developers, and act as an advertisement that states “If you want full access to the cow, buy it from Apple, so you can get your milk any way you want it!” and in the process, help build critical mass for developers learning the Frameworks, something they wouldn’t do otherwise for the less common platform (in terms of market share). For the practical calculation of market share, there’s the Windows platform, the Mac platform, and then there’s some small number of Linux X Windows software, but as of this time, Linux just doesn’t have a nearly unified enough GUI API that everyone uses, and the Linux platform for the desktop is (I believe) smaller than the userbase of the Mac, total, not even counting all the fragmentation. Then there’s the reality that the Linux platform tends to more strongly encourage the thought process that “All software is free” up to and including “no financial cost” meaning you can rarely sell much software for money for the software license itself: you need to plan on making money from supporting it, but that’s self-defeating in most consumer-level software: if you need technical support for most consumer-level software, chances are they failed in the design and implementation of the software in the first place!

  • http://opinion-nation.blogspot.com/ philipmach

    There’s a one-word reason that Carbon won’t be disappearing soon: Adobe.

    There’s also a pretty short reason that Adobe will be porting over to Cocoa: 64-bit API.

    All of which is kind of interesting because Carbon was introduced primarily to placate Adobe.

  • hdasmith

    The problem of getting a Cocoa layer to work as almost a translation layer for win32 or .NET is that .NET is constantly changing at the moment. MS’s next version of .NET could well change a lot of the present workings again.

    MS are shooting themselves in the foot with this. Whilst initial development for .NET is easy… very easy (I learnt .NET basic in a day) it’s near on impossible to keep up with MS’s changes to the way a programme is made. This includes simple things such as making a timer.

  • nat


    MS isn’t doing what they’re doing by accident. If they opened up their frameworks, they’d be sued to death by everyone who’s code and concepts they’ve stolen from over the years.

  • nat

    Oops, I meant WHOOSE, not who’s.

  • nat

    Wow, I should have quit when I was behind. WHOSE, not whoose, nor who’s. :/

  • Pingback: Response to “Is Mac OSX 10.6 the Death of Carbon?” « Phantombility’s Weblog()

  • dicklacara


    I think the word you’re looking for is WAZOO :D

  • nat

    Thanks dicklacara. I would give anything for a an EDIT button. :D

  • nat

    Excuse, I would give ANYTHING for an EDIT button!!!

  • nat

    Excuse ME, I would give ANYTHING for an EDIT button!!!

    Two words: WOW. :D

  • retnuh


    Sorry it was the “re-implementing both .Net and Win32 APIs?” that threw me off.

    To help cover some of the other responses, and some of the other good and bad stuff.

    First up if you have everybody coding to the top layer of and API then you’re free to swap out any lower unexposed layers as long as the functionality remains the same at the top. Proof of this can be seen with Delphi’s VCL which wraps up all the GUI side of win32 programming into a real nice OO framework. Its a shame Borland/Inprise/Borland didn’t do better advertising to the developers because most applications need very little changes when moving between new versions of Delphi. I’d use this as proof of how to deal with the changes in .net and win32 apis, its been done. Also if Cocoa were to be on top of .Net it would be bound to a single version of .Net, and if you’re only coding to Cocoa then the version of .Net below it wouldn’t matter much. That said I’m not sure that adding another layer on top of .Net would be a good idea performance wise.

    Speaking of performance though, a lot of developers aren’t all that worried about it anyways, they’re more concerned with how easy something is. This would have a good and bad outcome, mostly good for Apple and bad for Microsoft. Cocoa apps would probably run a little slower on windows and reinforce any negative stereotypes of windows because of the extra layering, both Cocoa and any extra services required to expose other required OS X services. The good being that it runs fine on OS X.

    Overall I’m not convinced that doing any of this would be worth Apple’s time. I think its possible and could hurt Microsoft in the long term if done right. But I see it as a distraction to Apple’s core focus. Having been a windows developer for um…. 11 years now Microsoft has done enough to annoy me into buying a iMac 1.5 years ago to try something new. That experience along with the iPhone has made me start learning Objective-C. To this end Apple will have a large enough market between the iPhone and Touch to make developers really take notice and once there might start looking at normal desktop apps. If this happens then it could be worth having Cocoa for win32, but why they’ve already switched a lot of people by this point.

    And yes I’ve been following the win32 -> OS X article on Ars, waiting for the last part, there’s a lot of things I agree with there. I could rant on this for awhile but I’ll save you all the discomfort.

  • dicklacara

    Thanks for the detailed explanation– I understand!

    As to being worth Apple’s time, I can see several advantages:

    1) Apple could sell its iLife and iWork suites on Win and tie it into a new, improved (renamed) .mac services platform
    2) Make Time Machine available as above with remote backup
    3) Sell its Pro apps on the Win platform

    Ideally, these would not work as well with the additional Cocoa layer. But they could have a superior (OS X-like) interface/integration amongst the Apple-supplied apps. This would show Apple well to Win users & possibly lead them to consider migration to the Apple platform.

    Finally, my intuition tells me that Steve Jobs feels that MS (and Sculley) deprived Apple of its due– widespread acceptance of the Mac & Mac OS. I believe, that this remains a goal & hijacking the Win APIs and wooing Win Developers is a step towards that end.

  • retnuh


    1) Doh…. yup didn’t think of that one.
    2) um… requires hard links, and I’d have to read up on ntfs internals to know if this would work, and its been awhile so honestly I don’t remember if its even an option.
    3) yes and no.

    The main thing is Apple makes money on the whole package, mainly hardware margins, software yes but they would probably have to charge more for their software to really make it a profit center. While your three suggestions could work, is it in Apples best interest to help sell more PCs? Apple’s very good at holding various features or colors (black macbook) as an up sell, same with their Pro apps being only OS X, having more cross platform apps kind of washes down the up sell considering its all Intel hardware now.

    The more I think about the idea the more I dislike it. If your main competitive advantage is the whole package, why spend time pushing something good enough on a market that is used to just that. I think it might undercut all their effort in getting people to switch since they really wouldn’t have to. The closest example I can think of is Sega, but I’d have to lookup how they’re doing now just being a software house.

    Its unfortunate that Apple had all the problems during the 90s that it did, otherwise things might be very different now. How exactly, who knows, NextStep or anything like it might have never been made for example.

    There’s still one thing missing that Apple really should take some more focus on, gaming, yes its much better now, but its one thing holding back the “computer experts” of most families and they’re going to push their families into what they know how to fix. And it shouldn’t be too hard as most non windows game development is opengl already, and yes they do need to cleanup the spec some, but after Microsoft’s failed push of DX10 it’d be nice to see someone else actively pushing in that direction, unless consoles are it now.

    Oh almost forgot, the iPhone SDK might already be enough to woo windows developers towards OS X. It certainly is for me, a potential 10+ million iPhones by the end of the year plus Touches, I don’t know the numbers but its got to be higher than the iPhones, on the same platform with wifi, storage, app store with software updates = yes please!!!! Actually what we’ll probably start seeing from this is more and more corporate apps being written for the iPhone after v2 firmware gets released. Afterwards if the development process is nice enough you’ll start seeing a push for more and more corporate desktop apps for OS X. Once you have that market its a win for Apple. 10.6 really needs to have more enterprise networking/administration type support to win over the corporate world. So lets see, earlier this year release SDK that gets a bunch of people interested in iPhone development, June release enterprise feature set for iPhone, Jan 09 ish release 10.6 with better/broader support for various network environments into a market that has just spent 6-8 months learning Cocoa touch apis all while using a mac and its not a hard shift to normal desktop apps from there.

  • http://coderad.net StrictNon-Conformist

    I just a few minutes ago had a weird logical inspiration/epiphany as to what Apple *really means* with the two bridges, or at least what it could mean: it doesn’t mean porting Cocoa Frameworks to Windows at all, not in the least! I think we can safely agree on a few points:

    1. Apple is into selling the TUE which requires native software on controlled and known hardware configurations, which greatly aids in stability.

    2. Regardless of OS and native GUI, non-native GUI’s on software always rankles the user because it breaks away from the system self-consistency in a jarring fashion.

    3. Nice hardware and a great OS without all the applications users want and need is a really worthless “solution” and can be exemplified to some degree by the examples of the Apple Newton and the Lisa: however great they were, they never had a large amount of usable software, and their overall price was way too high for mass market sales.

    4. Being able to run applications for another OS has some advantages, but it isn’t ideal due to GUI issues, and is fraught with the “Keeping up with the Jones’s” problem: the other OS will always be advancing and changing, and is a moving target. See WINE, or OS/2 when it could run Windows apps. It isn’t totally outside of the realm of possibility, but I don’t see it as an ideal situation.

    5. This is a developer’s conference, and such things tends to have things announced of greater interest to developers than to typical end-users, but of course, that’s not always the case: what’s of interest to developers has an overall larger picture interest to end-users, even if typical end-users don’t have the background to fully comprehend how it all fits together.

    6. Whatever Apple can do to enhance the availability of software for their OS and hardware combination, the better things are, but it doesn’t make an awful lot of sense from the TUE marketing to make too much of the Mac/iPhone/iPod Touch platform available for the easy taking.

    7. Run-time emulation/layers for other APIs sucks down performance, even done well.

    8. There is some middle ground with the most common OS platform, at least for a limited subset of applications: .NET frameworks.

    9. The Windows GUI messaging and overall model is notably different from Cocoa, but .NET is bound to be closer, and also .NET is setup to deal better with compositing GUIs than old Win32.

    10. If Apple were to release a sufficiently updated version of the OS to warrant 10.6 for this WWDC and make it available, it’d make sense that the features involved wouldn’t actually have much side-effects with application compatibility of existing Leopard applications, but would have another feature.

    Ok, that’s a bunch of reasons, not just a few :)

    There are two ways Apple could go:

    1. They could do the less likely, kludgy way (for the user perhaps getting less native-feeling applications) and reuse LLVM to do run-time JIT compiling of .NET IL applications into a Mac-native (mostly) application, with a few added on support libraries to do some of the Windows->Mac abstractions. This has the issue of the constantly changing .NET libraries to deal with, and the resulting non-native feeling applications.

    2. A far more satisfying way (if third party developers would go for it) would involve enlisting the interested third party developers for Windows applications to run their existing .NET (or, if really ambitious) Win32/Win64 code through a code converter that would assist (as much as possible) converting Windows-specific things over to Mac-compatible code, and leave the rest intact. This wouldn’t be a perfectly complete port in all cases, most likely: DirectX would be a PITA, and COM would also have issues. This would leverage LLVM already used in the OpenGL stack, but purposed for converting abstract syntax trees of Windows code to equivalent Mac code. This seems relatively reasonable for feasibility, considering it’d be easier to take the MVC frameworks and write wrappers around the Windows event handling/GUI model, than the other way around.

    Of course, I may be completely wrong, and I’ll find out before noon PST :)

  • Berend Schotanus

    “Apple could port the Cocoa API to other platforms, allowing developers to create applications using Xcode that could be deployed on both Mac OS X and Windows”

    Not being a software engineer and not used to working with API’s it’s not always easy to understand the technicalities explained. However, on a more strategic level it is interesting to see Apple appears to be focussing on the top layers of computer infrastructure. Apple is interested in end-users and the interface with them. Apple is interested in the top layer of programming. And for good reason, that’s where the value is. Having a “monopoly” on simple but essential core technology is one thing, having a relation with the people who are actually using it and being allowed to help them with their problems is something else.

    So we have iTunes for Windows, we have Safari for Windows, we get Cocoa for Windows, what’s next: selling Window Cocoa apps through the Windows iTunes store?
    Maybe even signed Cocoa apps, proving there is no malware onboard?

  • Pingback: AppleMania.info » Mac OS X Snow Leopard terá, sim, muitos novos recursos()

  • Pingback: Myths of Snow Leopard 5: No Carbon! — RoughlyDrafted Magazine()

  • Pingback: I know What I want! | byJoeyBaker()

  • Pingback: tecosystems » On GNOME: Gruber’s Wrong, But That Doesn’t Make Me Right()

  • Pingback: Mac OS Rumors()