Hypercritical
The Frontier
You have been recruited by the Star League…
Time to talk iPhone. Okay, so I’m a few months late, but at least I’m getting this out before the thing’s released. At this point, you may be wondering what’s left to say about the iPhone that hasn’t already been said. Truthfully, only a little, but I still think it’s worth saying. Here we go.
Right after the iPhone announcement, I tried to sum up the developer reaction in the form of an Apple Music Video. (Too bad "AMV" is taken.) The video was a bit obscure, but I still think it’s on target. Although I’m not a Mac developer, I am a programmer by trade, and as a Mac enthusiast I have little trouble putting myself in the shoes of a Mac developer. This is often my mindset while watching Apple keynotes, and was the case during the iPhone announcement.
The timeline of my reaction during the announcement mirrors the first 35 seconds or so of the video. The anticipation about a widescreen iPod had been building for a while, and I was curious to know what Apple’s take on a phone UI would look like. Maybe, just maybe, in the back of my mind I was considering what it would be like to write an application for the iPhone. But I’m (vicariously, remember) a Mac developer, not a “phone developer,” whatever that is. I (actually) worked for Palm for a while and saw what developing for phones is like. It’s not pleasant. And who knows what crazy Pixo OS this iPhone thing is running anyw—…Holy crap, it runs OS X! Must…develop…iPhone…app!
The instant desire to write an iPhone application can be explained by two things. The first is the obvious: Mac developers who know Mac OS X APIs can transfer that knowledge directly to iPhone development. What was once alien and intimidating becomes welcoming, and a whole new platform opens up to the Mac developer community.
But the second thing that attracts developers to the iPhone is more profound, and it explains a lot of the anxiety surrounding iPhone development. The iPhone is not just a new platform, it’s an entirely new set of rules for interface design. That is what struck me the most once the actual iPhone demos started. There are no windows, no close/minimize/zoom widgets, no checkboxes, no radio buttons, no scroll bars, no nothing.
Yes, there are features that look and act sort of like the traditional GUI widgets from desktop OSes. For example, there’s this vestigial little scrolling thing on the side of some screens (see, I was going to say “windows”), but it appears to simply be a visual indicator of scroll position. The actual scrolling is done by flicking your finger as if the entire screen is a big plank of wood floating on the water. Flick anywhere and whoosh, watch it glide. This is no scroll bar.
Historically, the presence of a stylus has enabled complex phone OSes to stubbornly cling to the conventions of the desktop GUI. The stylus makes checkboxes and radio buttons viable, if still a bit troublesome. And yeah, you can ask the user to drag his little pen along the 2mm-wide “scroll bar” on your smart-phone screen, or tap some tiny arrows. Hell, throw a menu bar on there while you’re at it. A stylus is like a mouse, right? The iPhone says no to all that, and in the process leaves behind everything familiar to application developers.
But what does an application behave like in this new world? What makes a pleasant, easy to use iPhone application? Where are the iPhone Human Interface Guidelines? No, seriously. Yeah, sure, we’re all such old pros that we can just ignore the Mac HIG and riff, right? After over 20 years of the Mac-like GUI, maybe that’s true. But you have to know the rules before you can know when to break them. We’re all in the dark on the iPhone.
And that includes Apple. Not only does Apple have to figure out what makes a good iPhone application, it has to actually create the APIs to produce such a thing. Okay, so no scroll bars, but surely there will be some standard way of scrolling, some standard gesture recognition engine, and so on. Apple has to create all this, if only for its own internal sanity, before it can really get cranking on iPhone application development.
And like the Mac GUI before it, there will be fits and starts, dead-ends, and bad ideas to shake out in the first few years. Also, an IDE would be nice. Xcode, sure, but some sort of simulator or remote debugger system would help. And, whoops, let’s keep revising all those APIs and that IDE to match the best practices as they evolve. Oh, and by the way, we need to ship something that works by June 29th.
Viewed in this context, the calls for third-party iPhone development, and Apple’s reaction to them, start to make a bit more sense. It’s the prototypical fanboy mistake to imagine that the mothership has infinite resources and skills, and any lack of satisfaction is malicious. The fact is, Apple could not provide a comprehensive third-party iPhone development environment on par with what Mac developers have come to expect by June 29th, even if it wanted to do such a thing—and there are many sound reasons not to. This stuff all needs time to cook.
In the meantime, Mac developers will have to be happy with some simple, WebKit-based development opportunities at WWDC this year. That’ll also be a nice gesture of good faith from Apple. Besides, who wants to make the first totally horrible “un-iPhone-like” third-party application to be ridiculed by John Geleynse at WWDC 2009? Letting Apple figure it out first isn’t so bad. Besides, then we get to snipe at their applications for the first few years.
Finally, let me get back to Apple’s reaction to the calls for third-party iPhone development. The flip-side of the fanboy mistake is the big corporation that doesn’t want to expose details of its internal decision making, so it dances around a particular topic. Apple’s definitely had its dancing shoes on when it comes to third-party iPhone development. Some of the statements have been merely evasive, but there’s one in particular that’s gotten people in a snit. It’s the idea that a poorly written phone application can do grievous damage to the cell phone network. To quote Jobs, “Cingular doesn’t want to see their West Coast network go down because some application messed up.”
Predictably, reaction to this has been quite harsh. Yes, I’m sure Jobs was motivated mostly by the desire to get people onto a new line of questioning, but he made the mistake of tickling the fanboy bone, triggering a wave of “I’m a technical person and I know that statement is bogus” blog posts. The fanboy mistake this time is assuming that the cell phone network and the carrier’s services are robust and reliable. A tiny application taking down a mighty phone network is laughable, right? Well, maybe not.
There are at least three things working against the robustness of the phone network, all of which combine to conceivably produce a scenario akin to that particularly infamous statement by Jobs. The first is the fact that phone companies in the US have only recently started to work with high-speed data over cellular networks. The second is that most data services are provided or otherwise touched by the carrier itself, usually as part of some wrong-headed lock-in strategy or attempt to get a piece of every transaction that happens on the network. Finally, this all combines to create a veritable monoculture within each phone network: every phone running roughly the same applications for common functions such as voice mail or email and so on.
Given this, it’s not hard to imagine how can one badly behaved application could cause big problems. In fact, I happen to know of one actual incident in which a bug in a certain first-party smart-phone application caused, essentially, a denial-of-service attack on an important data service—one that happened the same time every day for weeks before it was tracked down.
Now this is more of a condemnation of the carrier network and software culture than it is a reason to forbid third-party development. If anything, it argues more strongly for third-party development to both diversify the software landscape and to improve the reliability of the network itself, by necessity, in a trial by fire. So yes, Job’s statement is still a bogus excuse for denying third-party iPhone development, but I did want to point out that there is actually a kernel of truth behind the “take down the network” evasion.
Anyway, back on topic, the iPhone will definitely be a new frontier for developers. This is the most exciting part of the iPhone for me: a whole new set of rules for a new kind of UI. Who knows where it could lead—maybe even back to the Mac, some day. But as in the real frontier days, expect some hard river crossings, cholera, dysentery, and maybe, if we’re lucky, a bounty of wild fruit.