Archives for : mac

Bored Now

A thought occurred to me last year when Apple moved the new iPhone model to a late-year release, along with the new iPad mini, and a rev’ed iPad: what are they going to do in the first half of 2013?

Think back a bit: when the iPhone first came out, it was announced in January and went on sale in like July (months are approximate… I’m trying to avoid using seasons for fear of Northern Hemisphere bias. You’re welcome, Australia.) For a few years, iPhone was a mid-year product, with a corresponding iPod touch coming out later in the year. Then the iPad came out in early 2010 and was updated again in early 2011 and early 2012. But now, all of these products got late-2012 updates. So… what does that leave for the next six months?

Macs? The iMac got updated in late-2012 too, and the laptops have moved to a mid-year schedule (with an announcement at WWDC), better suited to back-to-school buying. Even if we do get the Mythical Modern Mac Pro in the next few months — and I am by no means optimistic about that — it’s a niche product.

And as developers, everything interesting is now a once-a-year update to iOS at WWDC. OS X is supposedly moving to an annual schedule, so that should be getting previewed soon (with an eye to mid-year release), but the simple fact is that very few of us can get Mac programming gigs, so it’s not worth the time of tracking an OS X beta and its new APIs very closely.

If Cocoa development is indeed a cargo cult — and it’s a pretty comfortable cult to be in if so — then the planes aren’t coming back with new stuff until July. Literally the only thing I can imagine happening before then is an Apple TV SDK, and there are few signs of that happening soon, or ever.

Continue Reading >>

13½th Mac

Before I’m even done updating all the copies of my bio to say I’ve owned 12½ Macs over the years, now I’m up to 13½.

I have a Mac Mini that’s on 24/7 to perform various server duties — most importantly, it’s an in-house Subversion server, but it has also been a Time Capsule remote backup and a public web server (when I feel like messing with port mapping on the DSL modem and wifi router). Since it’s on all the time, I don’t mind the kids playing their stuff on it, and they complained a few times over the past month that it got hung up on login. I figured it was the usual disk issues that come with time, but when I found that it took four tries to boot from DVD, I started to suspect that the logic board or memory was about to go, and I needed to move.

So, here’s the new Mini getting set up:

Migrating from old Mini to new

Note that the old Mini started life in 2006 as a Core Solo, and is the one that I levelled up with a Core 2 Duo in 2007. So my crappy thermal paste job held up for five years… not bad.

The new one seems really slow for a brand-new i5, but that may be my being spoiled by SSDs on my Mac Pro and new MacBook Air. Also, this is the bottom-of-the-line machine with integrated graphics that uses system RAM for graphics memory, so it’s a no-brainer to head over to Crucial or NewEgg to get 8GB tout suite.

Speaking of the Air, funny story there… remember, this is a 2011 Air that I bought the week before WWDC in order to teach a class, because I believe in buying what you need when you need it, and not trying to game retailer’s return policy when a new machine comes out. Thing is, the Air had some sort of severe problem where it would just black out — not shut down, not kernel panic, just entirely turn off — and come back up from a cold boot with the clock set to 1/1/12 00:00:00 GMT. That’s either a bad SMC, bad battery, or something else seriously wrong.

I took it to the Genius Bar in Grand Rapids, perhaps fortunate that it had blacked out with the lid closed on the way home from last week’s class in Detroit. I knew that from the system log, where there was one last entry from around 10:30 PM Monday (which would have been while I was driving home), and the next one was a boot at 1/1/12 00:00:00 GMT. Problems that come and go are a bitch to demonstrate to a seller, but this one could be documented, and once the geniuses hooked up the diagnostics, the battery test failed. In the end, they decided it was more trouble than it was worth to fix, and called me the next day to send me home with a new Air. I’d have been happy with a refurb 2011 Air — all I need is something that works and is equivalent to what I bought — but it turns out I came home with the 2012, with all its USB 3 goodness. I’ve heard of stories like this, maybe a little concerned that Apple has set customer expectations of special treatment, so I set my own expectations lower.

After all, optimists can never be pleasantly surprised.

Naming scheme update on the Mini: the old one was Dagger, with external partitions Eiko and Freya. Rather than using the next name in the well-established series — Yuna is already in use, and I’d like to save Ashe for a new Mac Pro someday — I switched to Dagger’s other name, Garnet. For anyone who doesn’t understand (and actually wants to), here ya go.

12½th Mac

I’m going to be teaching intro iOS development classes this summer at Develop Detroit (no, Detroit isn’t particularly close to Grand Rapids… shut up), and between that and the Core Audio all-day tutorial I’ll be doing at CocoaConf Columbus in August, I decided that it would be a good time to update from the 2008 MacBook that takes 10-15 minutes to build the largest of my client projects.

Of course, yes, this is me, the iPad partisan who leaves the laptop at home whenever possible. But the simple fact is, I need to be in Xcode to teach these classes, and Xcode for iPad hasn’t happened yet (though I still consider it inevitable).

Given my delight at the iPad’s light weight and super-fast SSD, I of course opted for the 11″ MacBook Air, with the 4GB RAM and larger SSD.

New MacBook Air (Ovelia)

Can’t tell if it’s fully practical for Xcode yet… I’m updating from a Snow Leopard machine with Xcode 4.2, so I need to run a bunch of system and software updates just to get Xcode runnable again. Tweeps assured me that Xcode can run on the Air, even with just 4 GB (as opposed to the 10 GB that finally satisfied my Mac Pro).

If you’ve ever seen my bio, you know it ends with a count of the Macs I’ve ever owned, and I now need to update that to indicate that I’ve owned 12½ of them. Offhand (and with device names, once I started assigning those in OS X):

  • PowerBook 160
  • Performa 6400/200
  • iMac (Bondi blue)
  • iBook (Bondi blue)
  • PowerMac G4 Cube
  • iBook (G3/900)
  • PowerMac G5 – [Aeris]
  • PowerBook G4 – [Rinoa]
  • Mac Mini (Core Solo) – [Dagger]
  • MacBook (early 2008) – [Agrias]
  • Mac Pro (early 2008) – [Yuna]
  • MacBook Air (early 2012) [Ovelia]

That’s 12. So what about the “half”? I’m surprised more people don’t ask me about that. Well, my first Mac was actually the Spectre GCR, a cartridge for the Atari ST that allowed it run as a full-on Mac emulator. It required a cartridge because you needed to get the 128K Mac ROMs as a service part and mount them on the cartridge — copying them into the software would be an obvious copyright violation. But once you were all set, the Atari 520 ST basically ran as a slightly-faster Mac Plus, supporting up to System 6.0.8 (I don’t think I ever put System 7 on here before getting my first PowerBook). Since all my friends in college had Macs, this was crucial for working on projects like the writing staff of Big Game Gaieties, for which the ability to read and write Mac discs was crucial (and a pretty impressive trick, considering Mac disk drives were variable speed, and Atari ST diskettes were constant speed).

Anyways, it wasn’t a real Mac, per se, but required some Mac hardware (the ROMs) and System 6, so I count it as half a Mac.

Seriously, would it be so hard to ship a new Mac Pro?

Can’t be a WWDC prediction because Apple would never expend precious keynote time on it, but why oh why can’t we have a new Mac Pro? Seriously, it hasn’t been updated in nearly two years, and if sales are poor, that’s probably a reflection of selling 2010 technology at 2012 prices.

I don’t see either the Mini or the iMac as a suitable replacement for the Mac Pro. For me, there’s a specific issue of drive technology. I put an SSD in my Pro as the boot drive, which has given me much needed relief from the 10-minute disk-thrashing festival that is Lion startup (#lionsucks), and provides a substantial (if not extraordinary) improvement for large Xcode builds. But I have traditional platters in the other bays to handle enormous amounts of media: my 1,000-album iTunes library, all my DVD rips, Final Cut and Soundtrack projects, etc.

SSDs are a terrible choice for big media files: the files are large, seldom accessed, and are read sequentially, meaning they gain nothing from the fast-access traits of flash memory, and certainly don’t justify the price. It’s gruesome to think of the idea of someone sync’ing their iPad to a MacBook Air and burning up a big chunk of the laptop’s storage with backups of the apps… a problem I didn’t think about until my kids’ iPads exhausted the puny 60 GB internal drive in the Mac Mini the family shares.

On the Mini, I have a 1 TB external drive that houses iTunes libraries (and now hosts the various “Mobile Applications” directories, which insist on living at ~/Music/Mobile Applications, but can be moved to another volume with a Unix simlink), my Subversion repository, old websites, etc. It’s not bad, but it’s a little kludgy to have external drives sprawling all over the desk.

Well, in a no-Pro future, we’re all going to have to make that choice: either use a traditional platter in the Mini or iMac and suffer the slowness, or boot on an SSD and then waste half its capacity or connect a bunch of external drives to hold all our media and iOS backups. Alex Lindsay keeps saying on MacBreak Weekly that Apple sees Thunderbolt as obviating most of the need for Mac Pros — Thunderbolt’s bandwidth supporting external storage, multiple displays, video input, etc. — but a sprawl of daisy-chained devices all over the place seems like a return to the bad old 80’s (check out what happens when you connect all the available peripherals to a TI-99). Furthermore, third-party Thunderbolt adoption has been disappointing, and it’s hardly unfair to say it’s just FireWire all over again.

Perhaps the other story is that Apple expects iCloud to serve our long-term storage needs for things like iOS device backups and media storage. I admit I haven’t given iCloud much of a chance — I activated the first beta during WWDC 2011 and soon had three copies of all my calendar events and contacts, so I’ve been slow to trust it with my data again. So, maybe this is their long-term answer.

But in the here and now, when I’m at my desktop, I want 3.5″ drive bays and monstrous CPU and GPU capacity. Screw the MacBook Pro — the iPad has all but obviated laptops for me — I want the pro Pro back.

Five Years, That’s All We’ve Got

As mentioned before, I’m not a big fan of panels at developer conferences, and whenever I’m in one, I deliberately look for points of contention or disagreement, so that we don’t end up as a bunch of nodding heads who all toe a party line. Still, at last week’s CocoaConf in Raleigh, I may have outdone myself.

When an iOS developer in the audience asked if he should get into Mac development, most of the panel said “go for it”, but I said “don’t bother: the Mac is going to be gone in 5-10 years. And what’s going to kill it is iOS.”

This is wrong, but not for the reason I’ll initally be accused of.

First, am I overstating it? Not in the least. Just looking at things where they stand today, and the general trends in computing, I can’t see the Mac disappearing in less than five years, but I also can’t imagine it prevailing more than another 10.

This isn’t the first time I’ve put an unpopular prediction out there: in 2005, back when I was with O’Reilly and right after the Intel transition announcement, I I predicted that Mac OS X 10.6 would come out in 2010 and be Intel-only. This was called “questionable”, “dumb”, and “ridiculous advice”. Readers said I had fooled myself, claimed I was recommending never upgrading because something better is always coming (ie, a straw man argument), argued Intel wouldn’t be that big a deal, and predicted that PPC machines would still be at least as common as Intel when 10.6 came out. For the record, 10.6 came out in August, 2009 and was indeed Intel-only. Also, Intel Macs had already displaced PowerPC in the installed base by 2008.

So, before you tell me I’m an idiot, keep in mind that I’ve been told that lots of times before.

Still, punditry has been in the “Mac is doomed” prediction business for 20 years now… so why am I getting on board now?

Well, the fact that I’m writing this blog on my iPad is a start. And the fact that I never take my MacBook when I travel anymore, just the iPad. And the issue that Lion sucks and is ruining so much of what’s valuable about the Mac. But that’s all subjective. Let’s look at facts and trends.

iOS Devices are Massively Outselling Mac OS X

One easy place to go for numbers is Apple’s latest financial reports. For the quarter that ended Sept. 30, 2011 (4Q by Apple’s financial calendar), the company sold 4.89 million Macs, 11.12 million iPads, and 17.07 million iPhones. That means the iPad is outselling all models of Mac by a factor of more than 2 to 1.

The numbers also mean that iOS devices are outselling Mac OS X devices by a ratio of at least 5.7 to 1… and it must be much more, since Apple also sold 6.62 million iPods (since these aren’t broken down by model, we don’t know which are iOS devices and which aren’t).

While the Mac is growing, iOS is growing much faster, so this gap is only going to continue to grow.

Goin’ Mobile

Let’s also think about just which Macs are selling. The answer is obvious: laptops. The Mac Unit Sales chart in this April 2011 MacWorld article shows Apple laptops outselling desktops by a factor of nearly 3-to-1 for the last few quarters. Things are so cold for desktops that there is open speculation about whether the Mac Pro will ever be updated, or if it is destined to go the way of the Xserve.

Now consider: Apple has a whole OS built around mobility, and it’s not Mac OS X. If the market is stating a clear preference for mobile devices, iOS suits that better than the Mac, and the number of buyers who prefer a traditional desktop (and thus the traditional desktop OS) are dwindling.

Replace That Laptop!

Despite the fact that it’s only about 28% of Apple laptop sales, I would argue the definitive Mac laptop at this point is the MacBook Air. It’s the most affordable MacBook, and has gotten more promotion this year than any other Mac (when was the last time you saw an iMac ad?). It also epitomizes Apple’s focus on thinness, lightness, and long battery life.

But on any of these points, does it come out ahead of an iPad 2? It does not. And it costs twice as much. The primary technical advantage of the Air over the iPad 2 are CPU power, RAM, and storage.

Is there $500 worth of win in having bigger SSD options or a faster CPU?

Few People Need Trucks…

“But”, you’re saying, “I can do real work on a Mac”. Definitely true… but how much of it can you really not do on an iPad? For last month’s Voices That Matter conference, I wrote slides for two talks while on the road, using Keynote, OmniGraffle, and Textastic… the same as I would have used on my Mac Pro, except for using Xcode to work with code instead of Textastic. I also delivered the talk via Keynote off the iPad with the VGA cable, and ran the demos via the default mirroring over the cable.

I’ve gone three straight trips without the laptop and really haven’t missed it. And I’m not the only one. Technologizer’s Harry McCracken posted a piece the other week on How the iPad 2 Became My Favorite Computer.

Personally, the only thing that I think I’m really missing on my iPad is Xcode, so that I could develop on the road. I suspect we’ll actually see an Xcode for iPad someday… the Xcode 4 UI changes and its single-window model made the app much more compatible with iPad UI conventions (the hide-and-show panes could become popovers, for example). And lest you argue the iPad isn’t up to the challenge, keep in mind that when Xcode 1.0 was first released in Fall, 2003, a top-of-the-line Power Mac G5 had a dual-core 2.0GHz CPU and 512 MB RAM, whereas the current iPad 2 has a dual-core A5 running at 1.0GHz and 512 MB RAM, meaning iPad is already in the ballpark.

…and Nobody Needs a Bad Truck

“But Mac OS X is a real OS,” someone argues. Sure, but two things:

  • How much does that matter – a “real OS” means what? Access to a file system instead of having everything adjudicated by apps? I’d say that’s a defining difference, maybe the most important one. But it matters a lot less than we might think. Most files are only used in the context of one application, and many applications make their persistence mechanism opaque. If your mail was stored in flat files or a database, how would you know? How often do you really need or want the Finder? With a few exceptions, the idea of apps as the focus of our attention has worked quite well.

    What exceptions? Well, think of tasks where you need to combine information from multiple sources. Building a web page involves managing HTML, CSS, JavaScript, and graphic files: seemingly a good job for a desktop OS and bad job for iOS. But maybe it argues for a task-specific app: there’s one thing you want to do (build a web page), and the app can manage all the needed files.

  • For how long will Mac OS X be a “real OS”? – Anyone who follows me on Twitter knows I don’t like Lion. And much of what I don’t like about it is the ham-handed way iOS concepts have been shoehorned into the Mac, making for a good marketing message but a lousy user experience. Some of it is just misguided, like the impractical and forgettable LaunchPad.

    But there’s a lot of concern about the Mac App Store, and the limitations being put on apps sold through the MAS. This starts with sandboxing, which makes it difficult or impossible for applications to damage one another or the system as a whole. As Andy Ihnatko pointed out, this utterly emasculates AppleScript and Automator. Daniel Steinberg, in his “Mac for iOS Programmers” talk at CocoaConf, also wondered aloud if inter-application communication via the NSDistributedNotificationCenter will be the next thing to go. And plenty of developers fear that in time, Apple will prohibit third-party software installs outside of the MAS.

Steve Jobs once made a useful analogy that many people need cars and only a few need trucks, implying that the traditional PC as we’ve known it is a “truck”, useful to those with advanced or specific needs. And that would be fine… if they were willing to let the Mac continue to be the best truck. But instead, the creep of inappropriate iPad-isms and the iOS-like limitations being put on Mac apps are encroaching the advanced abilities that make the truck worth owning in the first place.

The Weight of the Evidence

Summarizing these arguments:

  • iOS devices are far outselling Mac OS X, and the gulf is growing
  • The iPad and the MacBook (the only Mac that matters) are converging on the same place on the product diagram: an ultra-light portable computing device with long battery life
  • iOS is already capable of doing nearly anything that Mac OS X can do, and keeps getting better.
  • Mac OS X shows signs of becoming less capable, through deliberate crippling of applications by the OS.

Taken together, the trends seem to me like they argue against the future of Mac OS X. Of the things that matter to most people, iOS generally does them better, and the few things the Mac does better seem like they’re being actively subverted.

Some people say the two platforms will merge. That’s certainly an interesting possibility. Imagine, say, an iOS laptop that’s just an iPad in a clamshell with a hardware keyboard, likely still cheaper than the Air, and the case for the MacBook gets weaker still.

Given all this, I think OS X becomes less necessary to Apple — and Apple users — with each passing year. When does it reach a point where OS X doesn’t make sense to Apple anymore? That’s what I’m mentally pencilling in: 5-10 years, maybe after one or two more releases of OS X.


But in the beginning, I said I was wrong to say that an iOS developer shouldn’t get into Mac programming because the Mac is doomed. And here’s why that’s wrong: you shouldn’t let popularity determine what you choose to work with. Chasing a platform or a language just because it’s popular is always a sucker’s bet. For one thing, times change, and the new hotness becomes old news quickly. Imagine jumping into Go, which in 2009 grew fast enough to become the “language of the year” on the TIOBE programming language index. It’s currently in 34th, just behind Prolog, ahead of Visual Basic .NET, and well behind FORTRAN (seriously!).

Moreover, making yourself like something just because it’s popular doesn’t work. As Desktop Java faded into irrelevance, I studied C++ and Flash as possible areas of focus, and found that I really didn’t like either of them. Only when the iPhone OS came along did I find a platform with ideas that appealed to me.

Similarly, I greatly value the time I spent years ago studying Jini, Sun’s mis-marketed and overblown self-networking technology. Even though few applications were ever shipped with it — Jini made the fatal mistake of assuming a Java ubiquity that did not actually exist outside of Sun’s labs — the ideas it represented were profound. Up to that point, I had never seen an API that presented such a realistic view of networking, one that kept in mind the eight fallacies of distributed computing and made them managable, largely by treating failure as a normal state, rather than an exceptional one. In terms of thinking about hard problems and how stuff works (or doesn’t work) in the real world, learning about Jini was hugely valuable to me at the time I encountered it.

And had I known Jini was doomed, would I have been better off studying something more popular, like Java Message Service (which my colleagues preferred, since it “guaranteed” message delivery rather than making developers think about failure)? I don’t think so. And so, even if I don’t think the Mac has a particularly bright future, that’s no reason for me to throw cold water on someone’s interest in learning about the platform. There are more than 20 years of really good ideas in the Mac, and if some of them enlighten and empower you, why not go for it?

Throwing Cold Water on MacRuby for iOS

Fad du jour on Twitter is #welovemacruby, echoing a call posted here to bring MacRuby to iOS, calling it to Apple’s attention through the usual process of posting duplicate feature requests to

Please don’t. This is as bad an idea as I’ve heard in some time. The petitioners are only wasting their own time and Apple’s.

The reason I can say that is that Ruby was already tried and rejected as a first-class language for Mac development. In Leopard, Apple made Ruby and Python first-class languages for Cocoa development, creating Cocoa bindings for those languages and fully supporting them with Cocoa-Ruby and Cocoa-Python project templates in Xcode. Tutorials were posted… code was open-sourced… developer sessions were presented…

And yet, there’s no indication that there was any significant developer up-take. The Ruby and Python project templates disappeared in 10.6’s version of Xcode, a seemingly quick admission of defeat, or at least irrelevance.

Arguing this on Twitter, I put out a call to show me examples where any scripting language has delivered end-user applications on the desktop since the days of VB and Hypercard, or ever done so on mobile. To his credit, Philip Hodgetts fired back with some of his examples from the video production world. So far, he’s the only taker.

Still, I’ve long been impressed by the degree to which scripting languages have failed to be adopted for desktop and mobile development, given their dominance on the server side. Since the fall of VB, and setting aside the interesting case of browser apps running in JavaScript, substantially all major end-user desktop applications are written in C-derived languages, either compiled or running in a VM: C++, Obj-C, C#, and (if we’re extremely generous) Java. If Ruby and Python are so great, why haven’t they made greater in-roads into desktop development? Even if Apple were employing nefarious skullduggery to keep Ruby down — you know, just because Apple is evil and everything — why haven’t Ruby, Python, Scala and the rest of the hipster scripting languages taken over on Windows and Linux? (At least that’s my impression… I’ve searched for information on developing Ruby for Windows, and all I get is pages about devloping with Ruby on Windows, meaning to write your Ruby webapps on a Windows box, just like all these “Mac Ruby” developers seem to be web developers who own Macs. They’re writing webapps with Ruby, not desktop apps.)

I’m not going to say that the C-based languages are ideal for desktop and mobile development, but the fact that they haven’t been seriously challenged by the scripting languages, despite all the interest in and shared knowledge about scripting languages, makes me think that that they’re the best choice we have. It is not plausible to think that lots of developers haven’t already tried to use scripting languages for desktop apps. Surely they must have, and the results haven’t yet been compelling enough to dislodge the compiled C-based languages.

There’s one more thing. Inspired by the interest in the well-attended and voted-best-in-show Cocoaconf talk about the Accelerate framework (hardware-optimized low-level math and DSP functions), I posted a pair of tweets yesterday saying that good iOS developers were looking for ways to make their apps better, while Android developers were looking for ways to make their development experience better. On iOS, we’re willing to endure some developer pain in order to get apps running faster and looking prettier. Adopting a scripting language, with their inescapable overhead, runs counter to that. Android devs even acknowledge the performance advantage of the iOS software stack… so why mess that up with the overhead of a scripting language?

Thusfar, none of the really serious, really good iOS developers I know have retweeted their support for #welovemacruby. I don’t think that’s a coincidence. And I don’t think this is just an “Obj-C is what it is, take it or leave it” stance. I have yet to hear a case made for MacRuby on iOS. It won’t be faster, and while it might attract a few developers, the platform obviously doesn’t lack for active development. Indeed, the best argument made by the site is empathy (or pity) for the guy who works on it. I wish him the best, but I don’t see any evidence that MacRuby for iOS is going to improve individual iOS apps or the platform as a whole.

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…)

No launch-day Final Cut Pro X for me

Well, this was an unpleasant surprise:

Mac App Store rejects my purchase of Final Cut Pro X due to inadequate video card

I’ve never really given a lot of thought to my video card… I usually just get the default option for the Mac Pro when I buy it. It’s not like I do any gaming on my Mac (that’s what the Wii, PS2, iPhone, and iPad are for)

So here’s what System Profiler tells me I have:

ATI Radeon HD 2600 XT:

  Chipset Model:	ATI Radeon HD 2600
  Type:	GPU
  Bus:	PCIe
  Slot:	Slot-1
  PCIe Lane Width:	x16
  VRAM (Total):	256 MB
  Vendor:	ATI (0x1002)
  Device ID:	0x9588
  Revision ID:	0x0000
  ROM Revision:	113-B1480A-252
  EFI Driver Version:	01.00.252
  Resolution:	1920 x 1080 @ 60 Hz
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Rotation:	Supported
  Television:	Yes
Display Connector:
  Status:	No Display Connected

Guess I’m in the market for a better video card for an Early 2008 Mac Pro… what should I get, given that all I need it for is FCP?

Mobile Me Free? We’ll See.

One of the interesting Apple rumors bouncing around is the idea that MobileMe might become a free service.

I really don’t like MobileMe, or .Mac before it. I think it’s badly overpriced, charging $99 for services that are available elsewhere, and are often better elsewhere, for free.

But what I really hate about MobileMe/.Mac is a sense that Mac OS X has long been deliberately crippled in service of MobileMe. Many of the obvious and interesting uses of Bonjour, such as syncing your laptop and desktop, never appeared in Mac OS X and are obvious by their absence… and that absence is explained by the fact that Apple hoped to charge $99 to round-trip your files through their server farm, rather than performing the entire transaction within your household LAN (which, aside from being free, would be faster and more secure). Year after year, when the O’Reilly editors would ping the Mac bloggers about wishlists for MacWorld or other milestone events, I always made sure to put “an end to .Mac” as one of my requests. And I never got my wish. To quote my appearance in Chuck Toporek’s pre-Macworld 2006 ruminations: “Add to this the confusion of explaining .Mac to the switcher or new user, and I think you’ll agree that not only is .Mac overpriced, it may actually be harming the Mac platform. I hope that by the end of 2006 it [.Mac] is either free or dead.”

So maybe now we’re finally going to get it. And this is what makes me think Apple is moving in this direction: AirDrop, an announced feature in Mac OS X 10.7 (Lion), offering simple computer-to-computer file transfer, the kind of thing for which Apple had previously told us to use .Mac/MobileMe public folders. If they’re finally using Bonjour for easy computer-to-computer file transfer — like they should have been doing since about 2003 — then that makes me think that MobileMe has finally been sufficiently discredited to allow OS X to add these kinds of features.

What changed? As always with Apple, who the hell knows? But you have to think they’re at least a little surprised by the emergence of Dropbox as the de facto tool for exchanging files between your desktop and productivity applications on your iPad. Not MobileMe, and certainly not the clumsy file-exchange offered by iTunes. I’m actually really surprised by how totally Dropbox has won: all the text editors I evaluated for light on-the-go coding (*) support Dropbox, and few bother with MobileMe. Does that sting Apple? Maybe. Hopefully.

(* Textastic totally won this comparison, by the way. Not even close. If you think you ever might need to touch HTML or C or any other kind of code on your iPad, go get it.)

Now the fun question for me is, if MobileMe becomes free, will it be worth my time? I certainly don’t see a compelling reason to migrate my mail off GMail, or my documents off Dropbox, so except for the “Find My iPhone” feature, which has already been made free and which I still don’t use, it’s not clear that there’s anything there that I care about. Maybe I’m overlooking something… let me know in the comments.

Philip Hodgetts on Final Cut Pro rumors

I retweeted this already, but if you care about FCP, read Philip Hodgetts’ A new 64 bit Final Cut Pro? for some excellent analysis about what this could possibly be, given the respective capabilities and release timing of FCP, QTKit, AV Foundation, and Lion:

My biggest doubt was the timing. I believed a rewritten 64 bit Final Cut Pro would require a rewritten 64 bit QuickTime before it can be developed and clearly that wasn’t a valid assumption. Speculating wildly – to pull off a fully rewritten, 64 bit pure Cocoa Final Cut Pro – would require building on AVFoundation (the basis of iMovie for iPhone), which is coming to OS X in 10.7 Lion.