Cocoa and Objective-C: Up and Running (by me) is now available from O'Reilly.

Cocoa for Windows Will Not Happen

So after trading a couple of emails with John Gruber on the topic, I think we can safely say that the consensus is that Apple is not going to release Cocoa for Windows. In fact, I personally think the rumor about Windows API support in Leopard is more likely. Although the Windows rumor is still outlandish, there's at least a reason to do it.

Cocoa is Not OpenStep

Back before Cocoa even existed, NeXT had this thing called OpenStep. Although it started out as a part of the NeXT operating system, it eventually propagated to Windows and Solaris. Java's design, in fact, was influenced by Sun's experience with OpenStep.

Apple bought NeXT and acquired OpenStep in the process. By the time Mac OS X shipped, Apple had a new programming environment on its hands, called Cocoa. Some people will tell you Cocoa is just a newer version of OpenStep. I don't subscribe to this. Yes, a lot of the classes are very similar on the surface, but the way things fit together are quite different in places.

The Foundation part of the Cocoa umbrella framework, for example, is intertwined with CoreFoundation (or is it Core Foundation?). CoreFoundation was developed as part of the Carbon strategy, but it sits under Cocoa as well. That is, both NSArray and CFArray are both essentially instances of NSCFArray. This is a departure from OpenStep.

Cocoa uses Quartz, whereas OpenStep depended on the Display PostScript model. Furthermore, many applications that we think of as "Cocoa apps," are really a mix of legitimate Cocoa, CoreFoundation, CoreServices, Quartz, Carbon, and so on. Cocoa for Windows really wouldn't be enough for cross-platform apps.

Windows is not Mac OS X

OpenStep came at a simpler time. The contrast in higher-level desktop services was not quite so harsh as it is today. All you have to do is drag a window around an XP desktop to see how different things are from the Mac OS X window server.

Cocoa and many of the other public frameworks have hooks in Mac OS X infrastructure that simply doesn't exist in Windows (where for art thou, Spotlight?).  So Apple would either have to bundle all of this up with each app, or require users to download a runtime package. Yuck.

Taking it a step further, what should Apple do when it comes time to release a new version of Mac OS X and the supporting frameworks? Should they intentionally hold back functionality of Cocoa so to keep things doable on Windows? Or are the incompatibilities simply left to developers to sort out?

Either option is insanity. Runtime issues aside, we've seen what happens with "one size fits all" toolkits. They just never come together well on any one platform, it's just that Windows users don't seem to notice amidst all of the other distractions. In any case, Mac OS X would be dragged down to the lowest common denominator, which negates the effort of making a unique platform in the first place.

Where's the Motive?

Finally, we come to the basic question of what reason Apple would even have to release a version of Cocoa for Windows. Even assuming Apple doesn't package up all the supporting frameworks, maintaining Cocoa on Windows would be a significant effort. This is an entirely different beast than supporting Mac OS X on both Intel and PowerPC.

Then there's the obvious point that having unique apps is an important asset to Mac OS X. Regardless of how you feel as a developer, it's important to recognize that as a user of Mac OS X, your ability to use this platform is almost entirely dependent on unique software. If all apps for Mac OS X are available for Windows, many will simply use Windows.

Fortunately, Apple seems to really get this. They invest tremendous amounts of time and effort into making it ever-easier to create great apps. The implication is that this investment will be rewarded with software that is either unique to the Mac, or first/better on the Mac. If the same software could be deployed to Windows users, continuing to invest in Cocoa would be a waste of resources.

I've heard the argument that says cross-platform Cocoa will cause Windows developers to buy Macs to write their Windows software because it's so much easier and because people think Macs are cool and so on. Folks, I just don't buy it. In any case, Apple can't base a business around selling to a niche of Windows developers that want to buy a Mac to write Windows software.

Bottom Line

So in the Cocoa for Windows file, we have significant technical challenges, a lot of time and effort, user experience issues, and the lack of any sort of business plan. I just don't see it. Cocoa and the related frameworks really are for writing Mac OS X applications.

(That first line sounds like name dropping, doesn't it? Just didn't want to take credit for everything.)
Design Element
Cocoa for Windows Will Not Happen
Posted May 15, 2006 — 26 comments below




 

Zsolt — May 15, 06 1239

I agree. Apple's interest is not in making Windows PCs easier to use by making Cocoa run on them. Their interest is in making more people use Apple software, or at the least, Apple hardware (a la BootCamp).

Chris — May 15, 06 1240

A point about "Cocoa is Not OpenStep": CoreFoundation has a Windows port. It would not surprise me if Quartz (the CoreGraphics API, as opposed to the window server) had an internal Windows port as a proof of concept.

A port today would likely be simpler than OpenStep, in fact. The original OpenStep environment for Windows bundled Display PostScript. CF + CG + Foundation + AppKit would be a lot more efficient. There are a number of Carbon dependencies, but it wouldn't be unmanageable to remove them, or even maybe include a QTML-like subset of Carbon. You'd still have something more manageable than OpenStep for Windows, and a lot more amenable to producing apps that appear to be native Windows apps (if they ever bother to add a real layout manager to Cocoa).

I'm with you on the motivation, though. It makes about as much sense as Mac clones, or Mac OS for non-Apple x86. Although one might come up with a conspiracy theory about Apple porting more apps to Windows.

Jarl Robert — May 16, 06 1241

Where does all theese rumors spin from anyway? Some stuff is for windows, especially since apple has Itunes and Quicktime ported for it, other than that - why bother?

Scott Stevenson — May 16, 06 1242 Scotty the Leopard

Where does all theese rumors spin from anyway?

I think some of it started up once the Intel transition was announced.

Omid — May 16, 06 1243

Hey, I know this has nothing to do with your recent blog entry, but I was curious as to what you used to create this site.

I would email you, but I wasn't able to find it.

any info would be great.

thanks

Preston — May 16, 06 1244

I used to think the Cocoa for Windows rumors were bogus too, but Apple's done so many crazy, unthinkable things in the past 12 months that I've learned not to discount anything.

Scott Stevenson — May 16, 06 1245 Scotty the Leopard

so many crazy, unthinkable things in the past 12 months that I've learned not to discount anything

That may be, but it seems to me all of the other crazy things have some sort of motive.

Peter Jarvis — May 16, 06 1252

How to attract developers - show them the money...

Apple should port the cocoa infrastructure as it attracts developers. It would enable developers to develop/compile on a Mac and subsequently sell on Windows. The best sysytem does not always win - why?

Commercial Developers do not write applications for fun. As a developer I have to justify the cost of learning against potential return.

Network Effect applies to Programming too.

Scott Stevenson — May 16, 06 1254 Scotty the Leopard

Apple should port the cocoa infrastructure as it attracts developers

There's no question more developers are good, but the question is if the cost (both in actual dollars and unique titles) is worth it.

Kay — May 21, 06 1306

iTunes.

Jussi — May 22, 06 1314

At the moment iTunes is a Carbon application, and its Windows port shows that there exists at least a minimal port of Carbon for Windows, which is not a surprise given notorious QuickTime for Windows has been available for ages.

It is hard to tell what Kay had in mind about iTunes and Cocoa.

Kay — May 22, 06 1320

Of course you are right. Momentarily lead astray from the use of CoreFoundation, which was totally silly...

But my point remains: There was YB and while Quartz doesn't use DPS it uses PDF. Why should Apple have totally discontinued the Win32 branch in the code? Or do you even think they have thrown that away?

Once you have the basics working, the frameworks should run (with some extra work, granted). That's the whole point of frameworks.
Looking at iTunes today, I agree with you, the important part of Carbon seems to be working.

Scott Stevenson — May 23, 06 1326 Scotty the Leopard

Why should Apple have totally discontinued the Win32 branch in the code? ... Once you have the basics working, the frameworks should run

Getting things working well on WinXP might be harder than you think. Where's the analog for all the complex graphics that Quartz can do? What about all the supporting frameworks that most modern Cocoa apps need? Do you just have a ginormous runtime?

It could, of course, be done in some fashion if Apple was wanted to. The question is would the results be good on WinXP? Most importantly, what reason is there to do it?

Kay — May 24, 06 1329

I'm very aware, that it is not easy to do. But the basics I was talking about is Quartz and the low-layer stuff.
That's exactly what you'd want to get running, Cocoa/Carbon shouldn't have too many platform specifics in it (though it probably still has a surprising amount of those...).

As for the reason, it is a market. A big one. And already having a large portion of the code working (per YB) really helps. There had to be people around who knew how to do this kind of stuff, and after all simply throwing it away seems pretty wasteful.
Furthermore, why do you suppose had Apple went through the trouble of keeping a separate x86 build of OS X around since day one?
That also doesn't really make sense, unless you want to keep all roads open. The very same idea applies to the theory of a Cocoa implementation for Windows.

I am not saying that it is easy to do, nor that it is fully functional (and I wouldn't know for sure, anyway). But I seriously doubt that there isn't any code that makes it at least doable.

And yes, the supporting runtime would be huge. There'd be a whole lot of code which Apple would have to supply, from tiny things as the Objective-C runtime to some sort of DisplayPDF windowserver layer. There would of course also be stuff that simply wouldn't work, as IOKit and kexts.
But that is not the point. It wouldn't be about porting OS X to Windows, which wouldn't make sense, but rather supply the upper-level frameworks.
The stuff that interests the application developers.

Whatever, speculation. Given the cool new hardware roadmap, and the ability to run Windows if someone ever needed/wanted to, may make the mere thought obsolete. I wouldn't be disappointed ;)

Scott Stevenson — May 30, 06 1343 Scotty the Leopard

Cocoa/Carbon shouldn't have too many platform specifics in it

I'm not sure exactly what you mean by this.

As for the reason, it is a market. A big one.

There's a big market for writing Windows apps on the Mac?

why do you suppose had Apple went through the trouble of keeping a separate x86 build of OS X around since day one?

Because chip availability is unpredictable.

It wouldn't be about porting OS X to Windows, which wouldn't make sense, but rather supply the upper-level frameworks. The stuff that interests the application developers.

I just don't see it. It would be a partial implementation at best and it doesn't really further Mac OS X in any way. My basic feeling is that Apple is not NeXT.

Half Activist — Oct 11, 06 2033

I agree Apple may not release a windows API of cocoa on a strategically point of view, but on the feasability side, it wouldn't be that difficult.
You say that many classes from cocoa are 'toll-free bridged' with CoreFoundation types, such as CFArray etc, but the thing is Cocoa is an API and therefore we're talking about API compatibility not implementation differences. Furthermore, CoreFoundation is partly opensource and compiles on several platforms.
GNUStep would be able to bring cross platform development with Objective-C + OpenStep-ish APIs, only a little more things should be done in GNUStep but they definitly lack developers.

So, to me, Cocoa for Windows might never exist, but you tend to present it as a technical issue which is simply not true.

Scott Stevenson — Oct 11, 06 2036 Scotty the Leopard

but on the feasability side, it wouldn't be that difficult

I think we just disagree on this.

bobby Skinner — Oct 11, 06 2038

Apple does not have to port everything to windows, but simply a subset that is good enough to develop a decent app. The idea is not to bring every great Mac app to windows but to provide a good enough windows framework to win developers and bring their current windows only apps to the mac.

It is actually good that not every app could compile for windows. The goal is simply to be better that what MS offers to provide an incentive to move to Cocoa and get the mac market for free.

We hope one day they become mac only developers as they discover the OS X only stuff!

Scott Stevenson — Oct 11, 06 2039 Scotty the Leopard

The goal is simply to be better that what MS offers to provide an incentive to move to Cocoa and get the mac market for free

Technical challenges aside for a moment...

Other than the big names, I don't think Apple is all that eager to have Windows-like frankenstein apps on Mac OS X. That just makes it look like Windows with a different set of controls. Apple's goal is to attract developers who want to write new kinds of apps.

I also just don't buy that Windows developers would be willing to use Mac OS X tools to write Windows apps. NeXT actually tried that already, and it didn't exactly work out. Plus, other than homegrown enterprise stuff, how many Windows developers moved their apps to Java?

Wilko — Oct 16, 06 2079

I also just don't buy that Windows developers would be willing to use Mac OS X tools to write Windows apps.

As a developer who has programmed for Window, Linux (and now) OSX, I would have to agree 100%. Forget Windows legacy Win32/MFC crap, .NET is a great framework to program for and for obvious reasons, very well integrated with the Windows platform. Although Cocoa is a great framework too (and arguably better), it is a great OSX framework. Windows programmers will be more willing to move to .NET than Cocoa, which I think will never have the cohesiveness of .NET on Windows.

That's even without mentioning the development tools. Visual Studio Express and Pro editions are fantastic programming environemnts. XCode neads a lot of love, it doesn't even come close right now. I know, I use it every day.

For the record, (in case anyone is wondering), I think OSX is the superior platform.

Ken Wilcox — Oct 19, 06 2105

I have to admit I've liked reading this article as well as the comments. I too would like to see something like Yellow Box again, but I agree with Scott in that I don't see why Apple would want to do so.

An argument presented is that Apple already has applications on the Windows platform. True, but what applications are these. I only know of two - QuickTime and iTunes. Why did Apple make these for Windows?

My guess - Why would anyone encode a video and place it on the Internet and only have a small margin of individuals be able to play it. Apple wanted QuickTime to be used. To make it a strong selling point it had to be available for Windows.

iTunes. This should be obvious, but hasn't been mentioned. What was the iPod market share before Windows support was added? I don't know the exact number, but I knew very little about it before then. iTunes for Windows comes out, and the flood gates were opened. Now that the two are closely intertwined, you can't even get one without the other anymore.

Now reverse it. iLife for Windows? Heck no! That application bundle is what caused me to finally buy a Mac 2.5 years ago. This is a strong selling point for their hardware. If it existed on Windows, why buy a Mac. Caveat: I loved using the Mac 14 years ago when I was in graphic arts and have always wanted one, so it was an easy push.

Commercial Developers do not write applications for fun. As a developer I have to justify the cost of learning against potential return. - I've written several commercial "Windows Only" applications, and I've written a few apps/utils just for fun. I love learning new languages and platforms. Cost of learning? What about the cost of NOT learning? I think it's a great idea to explore new languages, tools and platforms. Sure, you can't always take what you learn and apply it everywhere to make money, but sometimes you can, and that's where the hidden rewards are. Your experience my vary, but this is what I've seen in my life.

why do you suppose had Apple went through the trouble of keeping a separate x86 build of OS X around since day one? Not only because of chip availability, but what about "chipset" lock in? People complain all the time about vendor lock in, why not chipsets? I now work for a company that makes embedded systems and I'm on the firmware team. We recently transitioned from a MIPS chip to x86. It took a lot less time that I thought it would and with what we learned we now have two other chips on the development board. So, it wouldn't surprise me at all if Apple had OSX for other chips. The Intel announcement was a disappointment, as I really like the PowerPC.

I'm new to Mac/Cocoa development, but I am enjoying the plethora of information that I'm consuming. Thanks Scott for making it readily/freely available! Sorry for the long post.

Brendan Dowling — Jun 12, 07 4331

You've got it wrong. Remember Steve Balmer's speech? Developers, Developers? The platform is the important thing. It's the network effect. People buy Windows machines because Windows is the platform for the applications they want to run. Apple wants to sell Macs. There are two ways to get people to buy Macs, get Macs to run Windows applications, or get developers to write apps for the Mac platform.

If Apple were to put support for the Windows API into Mac OS X many developers would stop developing for the Mac and only develop Windows API programs. Those applications would of course be "least common denominator" functionality that would work on the Mac, but probably wouldn't be able to fit in with the more advanced features of OS X, like Spotlight or Desktop Widgets or whatever.

Now, because at least 95% of machines out there are PC's, the software has to run on Windows. They're not going to target Mac unless they're either a niche developer who does things just for the Mac or are a massive developer that can afford to make a port for <5% of the market. And ports tend to be crappy. That's not really what Apple wants. They want a top-shelf experience for their users.

If, however, Apple makes all of its development tools and libraries available for Windows and provides technical support, at least some developers will shift over to it, if only for new projects. The business reasons make sense since developers can get access to a 5% larger market for free. Technically, it's not that hard for a developer to use one framework over another, it's just different stuff to learn. So if you could either use .NET and be able to sell your app to 95% of the market, or use Cocoa and be able to sell it to near 100%, which would you choose?

If Apple is successful with this, they will gain new applications and developers and perhaps attract more market share. Of course Microsoft could lose developers as developers start using Cocoa. Microsoft might get scared and start producing .NET for Mac. Either way, Apple wins and gets more applications.

It is my expectation that XCode and Cocoa and most of the related framework classes for Windows by the end of the year. And the Windows version will be capable of producing OS X binaries.

manpan — Aug 26, 07 4573

Some aspects of the Cocoa development environment have now indeed been ported to Windows but only via Apple's Safari browser. Apple could have ported Safari to Windows using Microsoft's .Net tools (or Sun Java) but instead used their own Cocoa environment for Safari on both Mac and Windows. Of course the original beta release of Safari for Windows (Safari 3.0.0) had bugs in it -- the Cocoa libraries for Windows in Safari had to be created from scratch -- it was new Cocoa libraries and so they had to be developed from the ground up with lots of bugs that would not have surfaced if Apple used .Net for Safari but they wanted Safari for Windows to still be a Mac like browser. Of course that is not to say a .Net based Apple Safari browser in beta on Windows would be completely bug free but have less bugs. In any case Apple is fixing the bugs with new updates and remember its still a beta release (Safari 3.0.3 beta is latest version -- finalized version will a more stable release as opposed to existing experimental releases) -- so there is some Cocoa support in Safari for Windows but so far that's it.

This was a good article though on reasons why Apple should not make Cocoa for Windows.

Ringo De Smet — Dec 25, 07 5291

I hope Apple will never support Windows directly. Remember IBM's Windows support in OS/2? I found the OS/2 desktop to be more powerful than Windows at that time, but their Windows support was partially responsible for not getting native support from app writers. The rest of the failure was the company itself.

navajo joe — Jan 19, 09 6597

Why would window user use "cocoa-nut"? .NET is there. For mobile we got .NET compact.

Fred — Mar 24, 09 6666

I have been developing Windows applications since 1987 and have literally grown up with Microsoft. Every programming tool they ever produced, I've used, abused, loved, hated and above all, never asked Microsoft to make them any slower...

The .NET framework is HUGE and despite writing fairly complicated software for a living, I have hardly used 20% of all the classes in it.

Recently I have been tasked to port (scratch that -- completely rewrite) a Windows Mobile application onto the iPhone. Hey what fun -- I didn't even have a Mac. I registered with Apple, downloaded the SDK and then furiously (stubbornly) attempted to install Leopard on a Microsoft Virtual PC. Finally caved in and ordered an iMac.

I got the iMac on Monday, installed the iPhone SDK, compiled a Hello World application in Objective C (which is all new to me!!!) and went home happy.

Yesterday I spent all day watching "Getting Started" videos on Apple's Dev Centre, and reading documentation on-line.

Today I wrote the first page of my mobile application, and it worked! At this rate I will have nailed it down by the end of next week. The original Windows Mobile application took six man months to complete by comparison, and wont be nearly as fast or powerful as the one I am working on now.

Microsoft's Visual Studio may be much more mature (in theory at least it has been around since 1992) than XCode. But they keep rewriting it all from scratch every three years or so, thus it never achieves stability and reliability. Every new version brings a host of irritating unwanted "features" (known as "bugs" to all but those who work for Microsoft).

XCode is refreshingly simple yet very powerful. Such elegance! I think I'm falling in love...

If only I could write all my Desktop applications in XCode (using the Cocoa framework) and just choose to compile for Windows, Mac, or iPhone, then I can die happy in the knowledge that finally humans have evolved real intelligence!

Heck, if only 5% of the computer market belongs to Apple now, there's no reason why they shouldn't aim a little higher. The rest of us will switch quickly if Apple behaved a little less selfishly. In other words, Apple shouldn't use Microsoft as a role model. Just give us developers simpler and more reliable tools, that gives us portability to boot. Please.

And as an aside, please ditch all the [ [object method] anotherMethod parameter:value] notation. This is damn hard to read folks. Learn this from C# -- keep it readable, use "." notation wherever possible (the Objective C compiler already understands "."s, so why not use them?).




 

Comments Temporarily Disabled

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




Technorati Profile
Copyright © Scott Stevenson 2004-2008