a‡Y Generations sideways
Matthew Baxter-Reynolds on the various toolsets available to mobile developers:
The fact is that if your day job involves sitting in Visual Studio writing C# applications, or building Java applications in Eclipse (which will be most of you - albeit not necessarily in Eclipse), when you fire up Apple's Xcode and start building CocoaTouch applications in Objective-C you're going to come face-to-face with a toolset that has not had the sort of love put into it that the open source community has put into the Java toolset and associate platforms, or that Microsoft has put into VS and .NET over the past 10 years. Apple has been caught on the back foot by the popularity of its tools and is at least one, if not two, generations behind. For example, the iOS version of Objective-C does not have garbage collection.
Leaving aside the mistake at the end (which Baxter-Reynolds corrects at the bottom of the article), I'd say that Apple's approach to its toolset is simply different, in some cases for the better, and in some for the worse.
Cocoa seems to be built on a simple premise: that developers know how to develop, but don't know how to design interfaces; which, I am sorry to say, is probably not far off the mark.
Thus, Apple's assumption is that developers don't need fifteen ways to parse an XML file, because they already share enough common knowledge to do it on their own-and if they don't, chances are that they will be smart enough to come up with their own solution and share it with the world.
The focus of Xcode is, instead, on creating an environment where even a person who is not well versed in user-experience design can still write an app that looks and feels good. Therefore, a lot of emphasis goes into good interface metrics, good look and feel, and so on.
In other words, Apple is counting on engineers commoditizing the aspects of software development with which they are most familiar, and focuses instead on filling the gaps in other disciplines that, traditionally, trip them up.
Case in point, Objective-C has lacked a public JSON framework for a really long time1. By all accounts, this should have made OS X and iOS very unsuccessful platforms for Web service-enabled apps; instead, developers simply built (and collaborated on) several JSON frameworks of their own. On the other hand, both of Apple's operating systems present their users with an environment in which apps use a consistent design vocabulary that is well within the grasp of even the hard-core Luddite.
There are two reasons why this is important. The first is that a lot of development is still done without the benefit of a designer's expertise. Even medium-size teams that build apps for large audiences place much more focus on engineering than on usability and ergonomics; thus, a toolset that promotes basic design principles can be beneficial from the get-go.
Second, even where designers are involved, developers are still responsible for implementing the code that makes design possible. Therefore, a development platform that emphasizes design creates a more collaborative environment for all involved.
That said, there are some aspects in which Apple's toolset has dragged behind its competitors. Memory management, for example, has long been one, but Apple's approach to solving the problem of managed memory has been a very deliberate one: they tried garbage collection, figured out that it didn't quite work (particularly on iOS, where resources are relatively scarce), and moved to a different solution (ARC) that somehow manages to create a managed-memory environment with less overhead than its unmanaged predecessor.
All in all, my personal experience has been that every development environment has its flaws and benefits. Even Xcode's focus on design doesn't prevent the creation of plenty of really horrible apps. Still, that's a far cry from saying that it's generations behind-I'd rather say it's generations sideways.
(Via Daring Fireball).
- Though that is getting resolved soon. a†©