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.)
Cocoa for Windows Will Not Happen
Posted May 15, 2006 — 26 comments below
Posted May 15, 2006 — 26 comments below
Zsolt — May 15, 06 1239
Chris — May 15, 06 1240
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
Scott Stevenson — May 16, 06 1242
I think some of it started up once the Intel transition was announced.
Omid — May 16, 06 1243
I would email you, but I wasn't able to find it.
any info would be great.
thanks
Preston — May 16, 06 1244
Scott Stevenson — May 16, 06 1245
That may be, but it seems to me all of the other crazy things have some sort of motive.
Peter Jarvis — May 17, 06 1252
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 17, 06 1254
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
Jussi — May 22, 06 1314
It is hard to tell what Kay had in mind about iTunes and Cocoa.
Kay — May 22, 06 1320
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
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
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
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
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
I think we just disagree on this.
bobby Skinner — Oct 11, 06 2038
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
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
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
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
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
This was a good article though on reasons why Apple should not make Cocoa for Windows.
Ringo De Smet — Dec 26, 07 5291
navajo joe — Jan 19, 09 6597
Fred — Mar 24, 09 6666
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?).