This article talks about the differences between developing for the Apple and Windows. Some of it I agree with, some of it I think is too simplistic.
For instance, the author claims that many Windows apps are poorly designed. Well, it’s not just Windows. It’s everywhere. Look at the “apps” on the web. Is Google’s Gmail really that well designed? What about Google Analytics?
Where Microsoft has gone wrong in my book is that they created a huge disparity between the Office look and feel and the Windows API for way too long. Well, actually the disparity is as large as ever at the Win32 level, but at least the .NET Framework is allowing .NET developers to get closer. This is an example of how I think the .NET Framework has essentially become the Windows API. Prior to the crowning of the .NET Framework I would have argued that MFC was the defacto Windows API (loosely), so this trend is nothing new.
Now in terms of the design issues within Windows development and design in general, I think this topic deserves a whole post. People are getting a bunch of issues muddled up. One point to keep in mind here is that many people are arguing about the current capabilities of the day. What do I mean? I’d argue much of the arguing about design has come forth precisely because we have better tools and technologies available today that enable us developers to “design” apps better. It’s not that one day we all woke up realizing that we had poorly designed apps and needed to make a change. It’s that one day we woke up and realized that the design tools and techniques were finally mass market. I realize that there’s more to it than this, but it’s an important point to realize. Down the road we will become more enlightened about other “bad” decisions that we’ve been making over the years too–and we’ll all look back and say “how could developers have made such a mess?”
A third issue the author brings up is about legacy. It’s important to realize that the minute a developer writes a drop of code, legacy begins. The minute a product begins testing legacy becomes a bigger issue. And so it goes as the product ships or gains market traction.
OS X has legacy issues like everything else. Try to write an ink-enabled app in OS X. You’ll most likely wind up having to work with two disjointed Mac Framewoks: Carbon and Cocoa. You’ll have to bridge the two because they weren’t designed to work equally together. It’s not terrible, but it’s a pain point–just like the Win32 API is and lets say WPF development.
Anyway, this post is longer than I planned it to be and much shorter than what I want to say, so I’ll leave it at this point and make a promise to go into each of these issues in greater detail later.