Rss

What Xcode 4 gets right (and Lion doesn’t)

It’s been a busy year for Apple user outrage, with radical changes to Xcode 4 and Final Cut Pro X provoking serious anger and lots of bitter denunciations on forums, blogs, Twitter and the like.

I can’t speak for Final Cut Pro X (I have yet to get my video hardware up to snuff), but frankly, I think Mac OS X 10.7 (Lion) deserves a lot more hate than Xcode 4.

And I’m happy to provide it.

Both have bugs, and with massive development, that’s not that surprising. I crash Xcode every few days. I get the spinning pinwheel of death from Lion every couple hours, in situations where it never occurred in Snow Leopard or earlier OS X releases. These will get smoothed out in time.

But once they are, what remains? Let me state my premise clearly: I like Xcode 4 because it’s built atop some fundamentally good ideas, and I dislike Lion because it’s not.

Let’s start with Xcode 4. Being on Lion, I can’t run Xcode 3 to reacquaint myself with the old days, but a few screenshots reminded me of some of its traits.

Xcode 3’s main window had a “Groups and Files” list on the left side. Except it didn’t have just files and groups of them. It also had an icon to represent your source code repository. And your recent searches. And smart searches. And bookmarks. And… you get the idea.

And that was before iPhone. Now Xcode had to handle provisioning, device management, remote debugging, archiving, and so on. iPhone development made demands that Xcode wasn’t really meant to handle, and it’s clear that iOS is going to be more and more important in the future, meaning that Xcode needs to be at least as aligned to iOS development as Mac, if not more so.

And this, to me, is what Xcode 4 gets right: it is a fundamental rethink of Xcode, informed by the first few years of iOS development. Its changes are radical, but in general, they’re based on cohesive and sensible ideas.

The biggest change in Xcode is how responsibilities are divvied up: the project workspace window is the container for anything related to a given project, and the organizer is for cross-project concerns like documentation, device management, source code repositories, and so on. Within the project workspace, there’s a fundamental left-to-right flow of specificity: a selection in the navigator sets the content area, and a selection in the content area can have further consequences in the utility area. That means we can pick files in the file navigator to bring them up in the source editor (the typical case), or use the log navigator to show build or runtime logs in the content area. The generic approach to the content area also opens up new opportunities: we already see this with Interface Builder incorporated as the editor for NIB files, and in Xcode 4.2, the content area offers up a new UI for editing storyboards.

Meanwhile, the now-prominent organizer makes the system of archiving builds more visible, which is critical not only because you now have to use this interface to submit to the App Store, but also because archiving is the only way to symbolicate and thereby make sense of crash logs you get back from Apple.

Quibble with specifics, or the roughness of a new codebase, but I do think Xcode 4 has its head in the right place. It’s built on fundamentally good, forward-looking decisions that put an end to the era in which Xcode frantically shoehorned in new iOS-related concepts, and is better positioned to adapt to whatever Apple throws at it over the next few years.

For a contrast, let’s look at Lion.

As with Xcode, I’ll set aside the annoying bugs — though I don’t know that I’ll ever forgive Lion’s Finder for losing the positioning of icons in most of my windows — and look at the ideas behind it.

What is the underlying concept of Lion? We’ve heard a lot about the importation of iPad features, notably the aggressive use of multi-touch gestures. The big one of these, of course, is the reversing of the scroll direction, dubiously spun as “natural” scrolling by Apple.

The problem with the iPad metaphors, for a start, is that there’s a fundamental difference between desktop and tablet gestures: desktop users are touching a proxy object like a magic mouse or trackpad. On the tablet, you can see the thing you’re touching; on the desktop, there’s a detach between the two.

In many ways, Lion seems optimized for laptops, which always have touchpads, and which enjoy a more intimate relationship with the user than a potentially sprawling desktop. As much as I hear the Mac Pro disk thrashing and see the aforementioned spinner, I also wonder if Lion isn’t really meant for use on machines with SSD storage instead of conventional hard disks.

And if Lion truly is optimized for portables, and if this is the reason for its seeming “iPad-ization”, I think it begs the question: why turn my Mac into an iPad, when I could just buy an iPad instead.

Honestly, I like my iPad. As I’ve said before, I like the iPad more than a laptop, and have gone iPad-only for my last few conferences. Thinking further ahead, the iPad is only going to get more powerful and more capable, while the traditional computer is fairly static in its abilities. Of all the things I need to do, the only productivity that’s really unavailable to me on the iPad is coding: there’s no Xcode for iPad, and it’s not clear whether a slimmed-down version would be possible with current hardware. But it’s not out of the question: Apple introduced Xcode in 2003, and the iPad 2 already outclasses a top of the line PowerBook of that era. In time, and probably not long from now, I’ll be able to do everything I care about on the iPad, and will be happy to.

So why compromise the desktop now, and turn it into something it’s not, which is to say a desktop OS with iPad features bolted on? Lion’s iPad-isms don’t really pay off for me, and what we’re left with is a mish-mash of incongruous concepts. Unlike Xcode 4, there’s no unifying concept behind Lion’s changes; instead, it feels like they’re trying to capture the iOS buzz and excitement, cramming in iPad-isms wherever they can be made to fit.

Steve Jobs famously made the analogy that desktop computers are like trucks, and that fewer and fewer people need trucks. It’s a clever and insightful analogy. The problem for me is that the people who need trucks don’t want those trucks turned into oversized sedans. What consistent ideas are present in Lion serve to work against what makes a desktop OS useful and productive in the first place.

The desktop OS doesn’t need a fundamental rethink; it may well be on a slow path to obsolesence, and it’s fine for Apple to let it go, as iOS is the heir apparent. But in lieu of a grand reinvention that is not likely, necessary, or needed, change for the sake of change is not welcome.

And don’t even get me started about the little things (monochrome icons in Finder sidebars, the hiding of ~/Library, Launchpad… must resist urge to hurt someone…)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.