Rss

Archives for : December2011

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.


Wrong

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 bugreport.apple.com.

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 welovemacruby.com 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.